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PREFACE 


This  report  is  one  in  a series  of  guidebooks  intended  to  assist  , 

system  program  office  personnel  in  software  acquisition  management.  The 
contents  of  the  guidebooks  will  be  revised  periodically  to  reflect 
changes  in  software  acquisition  policies  and  practices  and  as  the  result 
of  feedback  from  users. 

This  guidebook  has  been  prepared  under  the  direction  of  the 
Computer  Systems  Engineering  Directorate  (MCI),  Electronics  Systems 
Division  (ESD),  Air  Force  Systems  Command.  The  Software  Acquisition 
Management  Guidebook  series  is  currently  planned  to  cover  the  following 
topics.  (National  Technical  Information  Service  accession  numbers  for 
those  published  to  date  are  in  parentheses  where  available.) 

1.  Project  Guide  to  Content  Requirement  and  Audience  Needs 
(AD-A019124) 

2.  Regulations,  Specification  A Standards  (AD-A016401 ) 

3.  Contracting  for  Software  Acquisition  (AD-A020444) 

4.  Monitoring  and  Reporting  Software  Development  Status 
(AD-AO 16488) 

5.  Statement  of  Work  Preparation 

6.  Reviews  and  Audits 

7.  Configuration  Management 

8.  Requirements  Specification 

9.  Software  Documentation  Requirements  (AD-A027051) 

10.  Verification 

11.  Validation  and  Certification 

12.  Overview  of  the  Series 

13-  Software  Maintenance 

14.  Software  Quality  Assurance 

15.  Software  Cost  Estimating  and  Measuring 

16.  Software  Development  and  Maintenance  Facilities 

17.  Life  Cycle  Events 
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Software  Development  and  Maintenance 
Facility  Characteristics 


1 . INTRODUCTION 


The  primary  purpose  of  the  guidebook  series  is  to  assist  Air  Force 
program  office  personnel  in  planning  and  managing  the  software  aspects 
of  system  acquisition.  Among  the  critical  resources  that  require 
careful  planning  in  system  acquisition  are  facilities  necessary  for 
development  and  maintenance  of  computer  programs.  For  contracting 
purposes,  a Software  Development  Facility  (SDF)  or  Software  Maintenance 
Facility  (SMF)  can  be  viewed  as  a number  of  resources,  i.e.,  buildings, 
computers,  programs,  personnel,  etc. 

This  guidebook: 

• Examines  the  need  for  such  SDF's  and  SMF's  and  their  roles. 

• Indicates  policy  affecting  their  acquisition. 

• Identifies  key  management  decisions  and  technical  issues 
involved  in  their  planning. 

• Surveys  existing  SDF's  and  SMF's. 

• Identifies  potential  problems  and  provides  recommendations. 

This  information  should  be  useful  to  program  office  personnel  who  must 
plan  and  acquire  such  facilities  for  Air  Force  use  or  specify 
requirements  for  contractor  software  development  or  maintenance. 

A secondary  purpose  of  this  guidebook  is  to  inform  using, 
supporting,  and  higher  level  headquarters  of  the  need  for  facilities 
throughout  the  system  life  cycle,  from  early  development  through 
operations.  SDF  requirements  are  not  normally  recognized  early  enough, 
and  maintenance  support  following  system  development  is  sometimes  ill- 
planned  . 

SDF's  or  SMF's  may  be  acquired,  operated  or  managed  by  the 
Government,  contractor(s)  or  some  combination  of  the  two.  Generally, 
they  are  acquired  incidentally  as  a means  to  develop  operational 
software.  This  guidebook  focuses  on  SDF's  and  SMF's  acquired  within  the 
framework  of  the  800  series  of  Air  Force  regulations  (AFR  800  series). 


Only  SDF  and  SMF  requirements  for  command,  control  and 
communications  systems  are  discussed,  although  these  requirements  often 
overlap  other  applications.  This  guidebook  focuses  on  the  hardware  and 
software  issues.  Other  aspects  of  facilities  such  as  building 
construction  or  plant  engineering  are  not  discussed. 

The  reader  is  advised  to  examine  the  various  policies  and 
regulations  referenced  throughout  the  guidebook  for  further  details. 

The  remainder  of  this  section  describes  the  guidebook's  organization. 


\ #£FBGgpi N3  r 4fiK  ’HANK- NOT  FILMED 
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Section  2 discusses  the  need  for  SDF's  and  SMF's  within  the  context 
of  the  life  cycle  phases  defined  in  AFR  800-14,  Volume  II,  Acquisition 
and  Support  Procedures  for  Computer  Resources  in  Systems  [ 1 ] . 

Section  3 examines  SDF  and  SMF  characteristics  of  several  existing 
or  planned  command,  control,  and  communications  systems.  There  were 
important  reasons  for  doing  such  a survey: 

• To  examine  the  key  management  decisions  involved  in  planning, 
contracting,  and  operating  SDF's  and  SMF's. 

• To  examine  the  roles  and  types  of  support  hardware  and  support 
software  used  in  existing  SDF's  and  SMF's. 

• To  find  out  how  SDF  and  SMF  requirements  for  planned,  but  as  yet 
unacquired,  systems  have  been  specified. 

• To  uncover  common  problems  encountered  in  planning  and  using  a 
SDF  or  SMF. 

Significant  SDF  and  SMF  characteristics  for  all  surveyed  systems  are 
summarized  at  the  beginning  of  Section  3.  The  systems  are  then  briefly 
discussed  in  Sections  3.2  through  3-5  and  Appendices  A and  B for  the 
benefit  of  those  who  want  more  detail. 

Section  4 summarizes  the  key  management  decisions  and  technical 
issues  to  resolve  in  planning,  contracting  for,  and  operating  any  SDF  or 
SMF.  The  types  of  support  hardware  and  software  that  should  be 
considered  are  identified  and  various  trade-offs  are  examined.  Appendix 
C discusses  the  most  important  types  of  support  software  used  in  the 
systems  surveyed . 

DoD  and  Air  Force  policies  that  impact  SDF  and  SMF  planning  are 
also  discussed.  The  documents  in  which  their  requirements  are  specified 
are  identified,  and  the  steps  in  contracting  are  discussed.  Factors  to 
be  considered  at  Preliminary  Design  Reviews  (PDR's)  and  Critical  Design 
Reviews  (C DR's)  are  also  identified. 

The  survey  uncovered  several  common  problems  in  planning  and 
contracting  for  SDF  and  SMF  resources.  These  problems  are  identified, 
and  recommendations  for  avoiding  them  are  provided  in  Section  5. 
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2. 


SOFTWARE  DEVELOPMENT  AND  MAINTENANCE  FACILITY  ROLES  IN  SYSTEM 
ACQUISITION 


SDF's  and  SMF's  can  take  many  forms,  depending  on  the  management 
constraints  and  system  support  requirements.  This  section  discusses 
their  roles  within  the  context  of  acquisition  life  cycle  and  computer 
program  life  cycle  phases. 

2. 1 Acquisition  Life  Cycle  Phases 

Air  Force  direction  pertaining  to  defense  weapon  system  acquisition 
is  included  in  the  AFR  800  series  of  regulations.  Acquisition  life 
cycle  phases  are  defined  in  AFR  800-14,  Volume  II  [1]  as  follows: 

Conceptual  Phase.  "This  is  the  initial  planning  period  when  the 
technical,  military  and  economic  bases  are  established  through 
comprehensive  studies,  experimental  development  and  concept  evaluation. 
The  objective  of  this  initial  planning  may  be  directed  toward  refining 
proposed  solutions  or  developing  alternative  concepts  to  satisfy  a 
required  operational  capability." 

Validation  Phase.  "This  is  the  period  when  major  system 
characteristics  are  refined  through  studies,  system  engineering,  and 
preliminary  equipment  and  computer  program  development,  test  and 
evaluation.  The  objective  is  to  validate  the  choice  of  alternatives  and 
to  provide  the  basis  for  determining  whether  or  not  to  proceed  into  the 
next  phase." 

Full-Scale  Development  Phase.  "This  is  the  period  when  the  system, 
equipment,  computer  programs,  facilities,  personnel  subsystems, 
training,  and  the  principal  items  necessary  for  support  are  designed, 
fabricated,  tested,  and  evaluated.  The  intended  outputs  are  a system 
which  closely  approximates  the  production  item,  the  documentation 
necessary  to  enter  the  production  phase,  and  the  test  results  which 
demonstrate  that  the  system  to  be  produced  will  meet  the  stated 
performance  requirements." 

Production  Phase.  "This  is  the  period  from  production  approval 
until  the  last  system  item  is  delivered  and  accepted.  The  objective  j.s 
to  efficiently  produce  and  deliver  effective  and  supportable  systems  to 
the  using  command(s)." 

De pi oyme n t Phase.  "This  period  commences  with  delivery  of  the 
first  operational  unit  and  terminates  when  the  system  is  removed  from 
the  operational  inventory." 

The  acquisition  life  cycle  phases  of  a command,  control,  and 
communications  system  are  depicted  in  the  upper  portion  of  Figure  1. 
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2 . 2 Computer  Program  Life  Cycle  Phases 

According  to  AFR  600-14,  Volume  II,  the  computer  program  life  cycle 
consists  of  the  following  six  phases:  analysis,  design,  coding  and 

cneckout,  test  and  integration,  installation,  and  operation  and  support. 
Although  the  AFR  800-14  allocation  of  tasks  to  phases  is  somewhat 
arbitrary,  it  closely  approximates  what  actually  occurs  in  software 
production  and  use  of  command,  control,  and  communications  systems. 

The  middle  portion  of  Figure  1 identifies  the  computer  program  life 
cycle  phases  involved  in  production  of  such  a system's  operational 
software.  These  phases  could  occur  earlier  or  later  for  development  of 
support  software  (e.g.,  a compiler).  It  should  also  be  noted  that  there 
may  be  more  than  one  operational  software  Configuration  Item  (Cl),  that 
there  is  a separate  computer  program  life  cycle  for  each  Cl,  and  that 
these  life  cycles  may  be  independent. 

The  Software  Acquisition  Management  Guidebook:  Life  Cycle  Events 
[2]  describes  the  activities  and  products  within  each  phase.  The 
following  paragraphs  discuss  those  activities  associated  with 
development  of  the  operational  software  that  require  or  may  require  SDF 
or  SmF  support. 

Analysis . The  purpose  of  this  phase  is  to  define  the  functional 
and  performance  requirements  for  a computer  program  (i.e.,  Computer 
Program  Configuration  Item  (CPCI)).  For  operational  software,  the 
analysis  is  based  mainly  on  the  initial  version  of  the  system 
specification  which  is  a product  of  the  conceptual  phase  of  the 
acquisition  life  cycle. 

The  computer  program  life  cycle  analysis  phase  basically  falls 
within  the  time  frame  of  the  acquisition  life  cycle  validation  phase. 
Computer  program  development  specifications  are  produced  during  this 
phase.  It  should  be  noted  that  system  level  analysis  (e.g., 
requirements  analysis,  preliminary  system  design,  prototyping, 
modelling)  which  involves  some  software  analysis  may  occur  during  the 
conceptual  phase  to  analyze  various  tradeoffs  and  provide  a basis  for 
development  of  the  initial  system  specification. 

During  the  computer  program  life  cycle  analysis  jihase , various 
software  design  approaches  are  considered  and  trade-offs  performed.  The 
selected  design  approach  must  satisfy  the  requirements  as  defined  in  the 
system  specification  and  computer  program  development  specification  (see 
Appendix  A of  the  Life  Cycle  Events  Guidebook  [2]).  The  design  approach 
for  each  CPCI  should  be  reviewed  at  a PDR. 

Design . Design  includes  the  selection  of  algorithms,  data 
structures  and  computer  program  logic  necessary  to  implement  the  CPCI 
requirements . The  result  is  a detailed  definition  of  the  computer 
programs,  their  interfaces,  overall  program  flow,  division  of  programs 
into  units,  and  incorporation  of  features  to  facilitate  testing.  The 
design  approach  is  documented  in  the  preliminary  computer  program 
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product  specification.  This  specification  is  reviewed  against  the 
system  specification  and  computer  program  development  specification 
during  CDR. 

Coding  and  Checkout.  Coding  involves  the  translation  of  the  design 
into  programming  language  statements.  These  statements  are  then 
compiled  or  assembled  into  instructions  executable  by  the  operational 
computer.  Each  computer  program  undergoes  preliminary  checking  and 
debugging  to  verify  that  it  functions  satisfactorily  (e.g.,  generates 
the  appropriate  output).  The  Preliminary  Qualification  Test  (PQT)  for 
each  CPCI  may  begin  in  the  late  stages  of  coding  but  generally  occurs  at 
the  end  of  the  coding  and  checkout  phase. 

Test  and  Integration.  During  test  and  integration,  the  operation 
of  the  individual  computer  program  modules  is  verified  against  the 
requirements  specified  in  the  computer  program  development  specification 
and  ultimately  the  system  specification.  The  modules  are  integrated 
stepwise  until  the  total  system  is  built  and  tested.  The  use  of  top- 
down  structured  design  and  programming  techniques  could  alter  the 
sequence  of  events.  In  particular,  not  all  design  would  need  to  be 
completed  before  coding  began  and  there  might  not  be  a separate  series 
of  module  integration  tests  for  each  module. 

There  are  two  types  of  formal  testing  of  CPCI's:  PQT  (previously 

mentioned)  and  Formal  Qualification  Test  (FQT).  PQT  is  performed  for 
critical  functions  and  occurs  in  the  time  period  between  CDR  and  FQT. 

FQT  is  a complete  and  comprehensive  test  of  each  CPCI. 

Installation . Installation  includes  the  loading,  operation,  and 
testing  of  computer  programs  within  the  operational  environment. 
Following  the  completion  of  FQT's  for  all  CPCI's,  the  system  is  released 
for  system  level  Development,  Test  and  Evaluation  (DT&E).  System  level 
DT&E  is  a formal  qualification  of  the  total  system  against  the 
requirements  of  the  system  specification.  Such  system  testing  is 
performed  in  an  environment  as  near  as  possible  to  the  operational 
environment.  Initial  Operational  Test  & Evaluation  (OT&E)  is  performed 
prior  to  the  production  decision  which  terminates  the  full-scale 
development  phase  of  the  acquisition  life  cycle.  Initial  OT&E  may 
overlap  system  level  DT&E.  Follow-on  OT&E  is  conducted  after  the 
production  decision.  OT&E  measures  the  system's  military  utility  and 
operational  effectiveness. 

Operation  and  Support.  Follow-on  OT&E  is  continued,  as  necessary, 
during  and  after  the  production  decision  to  ensure  that  the  system 
continues  to  meet  operational  needs.  SMF 's  must  be  provided  to  support 
maintenance  of  operational  software  beginning  with  the  system's 
deployment . 

It  is  necessary  to  distinguish  between  software  maintenance  and 
development.  Maintenance  generally  involves  minor  modifications  of  the 
operational  or  support  software  in  order  to  correct  software  errors 
(e.g.,  latent  defects  discovered  after  qualification  testing)  or  adjust 
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system  parameters  for  a changing  operational  environment.  For  purposes 
of  this  guidebook,  maintenance  also  includes  minor  changes  to  system 
requirements  (e.g.,  low-level  type  Engineering  Change  Proposals)  that  do 
not  involve  major  development  of  software.  It  is  unrealistic  to  assume 
that  such  changes  will  not  occur,  and  a SMF  should  accommodate  these 
changes.  A new  SDF  may  need  to  be  established  or  an  existing  SMF 
upgraded  in  order  to  perform  major  system  alterations  or  upgrades.  The 
Software  Acquisition  Management  Guidebook:  Software  Maintenance  [3] 
discusses  in  more  detail  computer  program  maintenance  activities. 

2.3  Software  Development  and  Maintenance  Facility  Roles 

The  factor  that  distinguishes  a development  facility  from  a 
maintenance  facility  for  a specific  system  is  the  phase  of  the 
acquisition  being  supported.  A SDF  may  be  used  during  the  conceptual 
and  validation  phases  of  the  acquisition  life  cycle  to  support  system 
modelling  and  prototyping;  however,  a SDF  is  reouired  from  full-scale 
development  through  production  (see  Figure  1).  When  the  system  is 
deployed  a SMF  is  required.  It  should  be  noted  that  a SDF  and  SMF: 

• Are  not  necessarily  the  same  physical  facility. 

• May  have  different  users  and  operators. 

• Normally  have  different  approaches  to  facility  operations  and 
management, 

• May  overlap  in  time. 

There  may  be  more  than  one  SDF  or  SMF  for  a given  system.  In  some 
cases,  maintenance  is  performed  at  the  operational  site.  In  other 
cases,  maintenance  is  performed  at  a facility  which  supports  maintenance 
and  development  of  other  systems.  A SDF  or  SMF  may  also  support  user 
training  and  system  exercises;  however,  it  is  beyond  the  scope  of  this 
guidebook  to  discuss  these  latter  two  roles.  The  survey  of  typical 
SDF 's  and  SMF's  reported  in  Section  3 illustrates  all  combinations  of 
facility  roles. 

A SDF  or  SMF  may  include  more  than  one  support  computer.  Each 
computer  may  support  a separate  set  of  activities  (e.g.,  compilations, 
module  tests,  CPCI  FQT's).  The  set  of  hardware  and  software  that  one 
should  consider  in  supporting  each  of  the  computer  program  life  cycle 
phases  is  discussed  in  Section  4. 
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3. 


EXISTING  SOFTWARE  DEVELOPMENT  AND  MAINTENANCE  FACILITIES 


SDF's  and  SMF's  for  14  systems  were  surveyed  to  determine  what 
types  of  such  facilities  currently  exist  or  are  planned  for  command, 
control,  and  communications  systems  within  the  Air  Force.  Significant 
features  of  these  facilities  are  summarized  in  Section  3.1.  Appendix  A 
briefly  describes  each  system's  operational  role.  Four  of  the  14 
systems  have  been  selected  for  further  analysis  and  are  described  in 
Sections  3-2  through  3-5.  The  SDF's  and  SMF's  of  the  remaining  ten  are 
described  in  Appendix  B.  These  14  systems  provide  good  examples  of  the: 

• Major  decisions  involved  in  planning  a facility. 

• Different  roles  of  a facility. 

• Typical  support  hardware  and  software. 

• Transition  from  development  to  maintenance. 

In  order  to  gather  the  survey  data,  personnel  at  ESD  or  MITRE 
involved  in  each  program  were  interviewed.  Selected  sites  were  visited 
by  the  author  in  order  to  tour  specific  SDF's  and  SMF's  and  interview 
personnel  involved  in  their  planning,  management,  and  operation.  Many 
of  the  recommendations  listed  in  Section  5 are  based  on  these 
interviews.  The  survey  data  presented  in  this  guidebook  reflect  the 
status  of  the  systems  as  of  August  1976,  and  have  been  reviewed  for 
accuracy  by  the  ESD  organizations  responsible  for  each  system's 
acquisition . 

3 . 1 Significant  Characteristics  and  Trends 

Table  1 summarizes  the  significant  characteristics  of  the  SDF's  and 
SMF's  in  each  of  the  surveyed  systems.  The  solid  lines  in  Table  1 
separate  the  various  systems  (e.g.,  E-4  and  AFSATCOM  I).  Facilities 
within  each  system  are  delineated  with  a dashed  line.  As  an  example, 
there  were  two  SDF's  for  E-4:  one  at  the  contractor's  plant  and  the 

other  at  a subcontractor's  plant.  Most  of  the  terms  in  the  table  are 
self-explanatory  (e.g.,  System,  Location).  The  other  terms  are  defined 
as  follows: 


• Facility  (RoleJ : A facility  can  support  the  development  or 

maintenance  of  the  operational  system.  In  some  cases,  a 
facility  may  be  used  for  training  the  user  or  for  mission 
exercises.  The  primary  roles  of  each  facility  in  the  system  are 
listed.  The  type  of  facility  (SDF,  SMF,  or  both)  can  be  equated 
to  the  roles  listed  (development  or  maintenance). 

t Facility  (Type):  Two  descriptors  are  used  to  typify  how  a 

facility  is  used.  A shared  facility  is  a facility  that  supports 
the  development  or  maintenance  of  more  than  one  system.  A 
dedicated  facility  is  a facility  that  supports  only  one  system. 
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• Support  Hardware  (Type):  The  primary  types  of  processors  used 

to  develop  the  operational  software  are  listed. 

• Support  Hardware  (Same  Type  Proc.  As  Op.  Sys.):  This  heading  is 

an  abbreviation  for  "same  type  processor  as  operational  system", 
and  each  entry  indicates  whether  the  processor  used  to  develop 
the  software  is  the  same  as  that  used  to  run  the  software. 

• Support  Hardware  (Source):  The  source  of  the  support  hardware 

is  listed. 

• Support  Software  (Type):  The  primary  support  software  used  to 

develop  the  operational  software  or  new  support  software  is 
listed.  Section  4.3.1  describes  the  differences  between  support 
software  and  operational  software. 

• Support  Software  (Off-the-Shelf ) : This  entry  indicates  whether 

the  support  software  is  off-the-shelf. 

The  use  of  the  term  "undetermined"  (abbreviated  as  "undet.")  refers 
to  whether  a particular  location,  computer,  etc.  has  been  selected. 

Where  detailed  requirements  have  been  established  in  a Statement  of  Work 
(SOW)  or  specification,  the  requirements  are  summarized.  The  remaining 
abbreviations  are  defined  as  follows:  Contr.  (Contractor),  Subcontr. 
(Subcontractor),  Develop.  (Development),  Maint.  (Maintenance),  Ded. 
(Dedicated),  Op.  (Operational) , Appl . (Application),  Exec.  (Executive), 
Modif.  (Modification),  Config.  (Configuration),  Spec.  (Specification), 
and  Microprog.  (Microprogramming). 

Based  on  Table  1 and  the  supporting  data  in  Appendix  B,  the 
following  general  characteristics  and  trends  can  be  observed: 

• Each  system  requires  or  has  required  a development  facility. 

• Most  of  the  development  facilities  have  been  established  at  a 
contractor  or  subcontractor  plant. 

• Most  of  the  maintenance  facilities  have  been  established  at 
Government  owned  and  operated  locations. 

• Maintenance  of  the  software  is  not  usually  performed  at  the 
original  development  facility. 

• Development  facilities  are  generally  dedicated. 

• Contrary  to  what  one  might  expect,  most  maintenance  facilities 
are  dedicated. 

• A number  of  systems  performs  maintenance  at  the  operational  site. 
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Table  1 (Continued) 


SYSTEM  FACILITY SUPPORT  HARDWARE SUPPORT  SOFTWARE 


U, 

i 

i 

X 

i 

i 

X 

rH 

u 

i 

i 

rH 

CD 

X 

i 

i 

X 

*0 

a 

CO 

a> 

i 

i 

0) 

co 

1 

> 

i 

i 

z 

• 

i 

CO 

o 

i 

i 

a 

CD 

X 

JQ 

i 

* 

o 

a 

X 

C 

i 

i 

o 

rH 

X 

1 

i 

i 

0> 

i 

Cl, 

<D 

i 

C0 

CO 

CO 

i 

X 

> 

Cm 

CO 

fcu 

a> 

i 

<D 

0) 

0) 

i 

•H 

CD 

Cm 

CD 

o 

CO 

i 

X 

X 

X 

i 

z 

Q 

o 

X 

i 

i 

a 

i 

i 

3 

i 

i 

• 

O O 

i 

i 

4-3 

t. 

i 

i 

i 

cO  • 

O X 
a o 

i 

4-3 

O 

1 

CD 

i 

M 4J 

•> 

co  cd 

i 

c- 

a 

43 

> 

z 

i 

* 

0)  C 

CO 

1m  a 

a> 

i 

o 

a 

w 

•r-i 

L 

OO 

i 

•* 

L 

3 -H 

L. 

<V  CJ 

> 

i 

•o 

a 

T5 

3 

o 

a 

a 

O 

*“ 

i 

0) 

0)  <0 

CD 

c 

o 

f 

L. 

a 

L. 

co 

X 

C 

o 

a 

i 

0) 

rH 

O £ 

rH 

CD  B 

JD 

i 

CO 

3 

CO 

CD 

CO 

co 

ir» 

i 

rH 

a 

w 

a 

O <0 

< 

i 

X 

CO 

T3 

o 

o 

T3 

1- 

rH 

X 

i 

c 

•H 

6 

/it  «. 

,—1 

s 

1m 

CO 

i 

c 

C 

X 

X 

•H 

CD 

3 

i 

M 

a 

(D 

w 

ft 

o 

CD  W 

a 

CD 

i 

CO 

o 

CO 

co 

CO 

CO 

a 

e 

t- 

i 

> 

e 

CO 

a >-» 

VJ 

CO 

a o 

X 

CD 

i 

4J 

Q 

4-3 

\ 

\ 

a> 

c 

•H 

o 

i 

o 

o 

CO 

co  O 

£ 

CO 

CO  L. 

X 

00 

i 

CO 

O 

co 

CO 

CO 

cc 

M 

CO 

x 

i 

i 

-D 

o 

< fcH  a 

c 

x a 

4-3 

i 

i 

c 

i 

X 

i 

e 

CO 

» 

4-> 

i 

o 

rH 

i 

•H 

• 

i 

• 

• 

t- 

a. 

i 

i — 4 

X 

C- 

i 

L 

t- 

0-4 

i 

•H 

c 

43 

43 

* 

a 

a 

co 

i 

O 

•H 

•H 

c 

i 

c 

c 

o 

"O 

L 

i 

4-3 

r— 4 

O 

i 

O 

o 

X 

0) 

4-> 

i 

U-t 

CO 

•H 

O 

i 

o 

o 

> 

c 

i 

•i-4 

O 

a 

i 

a 

a 

o 

o 

o 

i 

Cl. 

X 

co 

3 

i 

3 

3 

CO 

Z 

o 

i 

i 

i 

<£ 

[3 

CO 

i 

i 

t 

CO 

CO 

o 

i 

i 

i 

i 

i 

i 

o 

i 

i 

ce 

i 

i 

cl. 

. 

i 

i 

CO 

i 

i 

U3 

X 

i 

i 

CL. 

CO 

i 

i 

X 

i 

i 

X 

i 

i 

a. 

i 

i 

W 

o 

i 

i 

z 

to 

i 

i 

CO 

CO 

«< 

CO 

<D 

i 

O 

o 

o 

i 

<D 

CD 

00 

<c 

X 

i 

z 

z 

z 

i 

i 

X 

X 

i 

i 

, — 

i 

CD 

i 

i 

i 

CD 

r— 

c 

i 

=r 

i 

43 

*“ 

‘H 

i 

t- 

CC 

x 

c 

o 

O 

CO 

i 

<D 

CO 

i 

o 

t*“ 

E 

rH 

X 

•o 

<m 

i 

rH 

cq 

i 

o 

m 

CD 

CO 

CD 

O 

i 

rH 

X 

i 

VO 

V 

cc 

C 

CO 

CO 

IE 

i 

CO 

z 

o 

CJ 

CO 

i 

vO 

CO 

H 

<D 

X 

CD 

CD 

i 

CD 

oo 

CO 

i 

-C 

E 

a 

*> 

O 

* — 

i 

a 

’ — 

a 

o 

1 

i 

o 

z 

43 

t. 

hr.  x 

CO 

* 

i 

bn 

< — 

c 

x 

o 

=T 

i 

Q 

X 

■H 

<D 

3 

Qu 

rH 

ITS 

i 

3 

IT* 

o 

f— * 

C_) 

f- 

i 

i 

i 

O 

X 

i 

X 

X 

C_) 

CO 

X 

i 

i 

i 

i 

X 

X 

o 

i 

i 

i 

T5 

■O 

i 

i 

i 

i 

<V 

<D 

i 

CO 

i 

L 

0. 

i 

• 

a. 

i 

on 

(0 

i 

•o 

a 

i 

i 

i 

i 

a 

CO 

a 

CO 

i 

i 

• 

i 

s 

i 

i 

i 

o. 

i 

i 

i 

a 

i 

• 

o 

i 

o 

4-> 

i 

4-3 

• — i 

i 

rH 

CO 

c 

i 

<D 

c 

<D 

i 

0) 

X 

•H 

i 

e 

•H 

> 

i 

> 

O 

a; 

i 

i 

i 

o 

CO 

2 

(D 

Q 

i 

i 

i 

CD 

Q 

1 

i 

E 

i 

i 

i 

o 

t- 

i 

CO 

i 

o 

43 

i 

CO 

1 

CO 

X 

c 

i 

z 

i 

c 

rH 

o 

i 

a 

o 

i 

c0 

rH 

o 

i 

(0 

t— 1 

C0 

co 

i 

X 

CO 

a 

» 

• 

(N 

£ 

i 

•H 

3 

i 

t- 

Li 

<*: 

X 

CO 

i 

4-> 

co 

i 

<D 

a 

O 

<d 

co 

1 

o 

CO 

•H 

i 

a 

c 

O 

X 

• — i 

i 

Cl. 

Cl. 

C 

43 

i 

<0 

o 

x 

CO 

l 

*=c 

< 

(0 

i 

-3 

o 

X UJ 
<C  Q 
CQ  Z 
Z 

o rc 
o o 


oo  CQ 
X I 
Z X CO 
O H K 
cj  O a. 


18 


Operational  Maint . Ded . Hughes  Yes  Delivered  Same  as  Contr 

Site  Operations  H5118M  by  Contr.  Facility 


Table  1 (Continued) 


0 a>  *8  a>  +> 

1 3 o u 

<u  >,  o o 

G Q)  if'  (0  a 

E C O 4J  Q. 

o o ^ n)  3 

U I I Q !/l 


4J 

1 

4-> 

1 

4-> 

O 

1 

O 

1 

0 

CO 

(0 

1 CO 

CO 

1 co 

(0 

0 

L 

L. 

1 0 

L 

1 0 

c- 

u 

4-) 

4-> 

1 C_> 

4-> 

1 0 

4-> 

C 

c 

f 2: 

c 

1 2: 

c 

3 

O 

0 

• 2 

0 

1 2 

0 

3 

O 

0 

1 3 

0 

1 3 

0 

Q-. 

0)  I <•_.  | 

o co  co  co  co 

t-  O 4->  >> 

O CO  O CO  CO 

cl>  2: 

C/)  O 3c  <0  t- 

O t*  O 

c_>  ■*->  - Q)  a.  • 

ZE  c e c 0.  p 

3 o a>  <d  3 <u 

3 (_)  40  o co 


<0 

L.  (0 

rH  <D  ' 

rH  » C O 

a)  to  0)  ^ 

3 ' O co 

>»  o 

<J)  IT>  «5  < 
C O 4->  > 

O 'O  «J  o 
33  X Q 2 


O 

CO 

1 • 

1 

0. 

O. 

4-> 

1 CL 

4-J 

1 a 

0 • 

4J 

0 co 

c 

1 O 

O 

c 

1 0 co 

rH  4J 

CO 

rH  CO 

CO 

<D 

1 rH 

O 

d) 

1 rH  0 

a>  c 

<D  O 

F 

1 o> 

CO 

e 

1 <1)  2 

> -H 

<D 

> . 

2: 

t»0 

1 > 

tc 

1 > 

0)  (U  a 
o 2:  o 


e o 

I 0)  4-> 

C 4->  rH 

O to  t H 

u >.  rt  a) 

00  CO  rH  3 ^ 
O 0)  H >»  O 

U o H R 5)  ® 

2:  *-  o -H  c o 

3 O t-  co  O 

3 U4  P w E X 


e o 

I CD  *-> 

C rH 

o n t.  h 

o >,  <o  a> 

CO  CO  rH  3 
O <u  -H  >,  O 

O O f-H  E <D  GO 

X t-  O -H  c o 

3 O t CO  O'O 

3 u*  ^ :c  x 


c 

•H  X 
<0  CD 

Q 4->  rH 
< C Q. 

as  3 E 
OOO 
Z X u 


20 


Maint.  See  Above  Contr.  & See  Above 

Operations  ENT  AFB 

Computers 
Moved  into 
Mountain 


Table  1 (Continued) 


tion  of 


Table  1 (Continued) 


A 


1 


• The  support  software  is  generally  off-the-shelf;  however,  some 
portions  of  the  support  software  for  certain  systems  (e.g.,  E- 
3A)  were  newly  developed. 

• Some  systems  have  not  established  any  definite  plans  for 
maintenance,  despite  a need. 

• Facilities  for  development  or  maintenance  are  generally 
expansions  of  the  operational  system  with  peripherals  necessary 
to  support  software  development  or  modifications. 

• Maintenance  support  is  generally  a subset  of  the  development 
support . 

• The  types  of  maintenance  performed  vary  greatly  from  simple 
release  of  the  operational  software  at  new  sites  to  major  system 
modifications . 

• In  some  cases,  the  hardware  at  the  contractor's  facility  is 
moved  to  a Government  maintenance  location. 

• In  most  cases,  the  operational  software  is  developed  by  more 
than  one  contractor  or  Government  agency. 

3.2  E-3A  (AW ACS) 

The  E-3A  system  was  selected  for  further  analysis  since  it  included 
several  development  laboratories  (i.e.,  sets  of  computer  equipment  and 
other  hardware  within  a facility),  has  a long  history  of  development, 
and  illustrates  the  transition  from  development  to  maintenance.  The 
iiodel  I phase  of  E-3A  was  contracted  in  July  1970  to  Boeing  on  a cost 
plus  incentive  fee  contract.  As  of  August  1976,  Model  I software  was 
undergoing  system  test  at  the  Boeing  plant  and  E-3A  test  flights  were 
being  flown.  The  operational  Model  I software  will  be  delivered  to 
Tinker  AFB  in  conjunction  with  the  first  production  delivery  of  the  E-3A 
in  March  1 9 77  - 

The  Tactical  Air  Command  (TAC)  and  the  Air  Force  Logistics  Command 
( AFLC ) will  maintain  the  Model  I software  at  Tinker  AFB.  Concurrently 
with  Model  I software  maintenance,  the  E-3A  program  office  will  be 
developing  follow-on  software  models  in  conjunction  with  E-3A 
enhancement  activities. 

I 

An  AWACS  Life  Cycle  Computer  Program  Management  Plan  delineates  a 
concept  for  development,  transition,  and  operation  of  AWACS  software  and 
discusses  the  E-3A  facilities,  hardware,  software,  configuration 
management,  testing,  organization,  manning,  and  training.  An  E-3A 
Software  Support  Pnase-in  Plan  outlines  the  tasks  to  be  performed  during 
early  operation  of  the  Tinker  AFB  maintenance  facility. 

An  E-3A  Transitional  Phase  Operational/Support  Configuration 
Management  Procedures  (0/S  CMP)  provides  more  detailed  plans  and 
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procedures  to  be  used  for  software  maintenance  during  the  transitional 
phase  of  the  program.  This  document  provides  an  in  depth  treatment  of 
such  subjects  as  configuration  management,  problem  reporting,  testing, 
documentation,  organizational  interfaces,  and  the  concurrent  maintenance 
of  Model  I with  the  ongoing  development  of  Model  II  software. 

3-2.1  Acquisition  Approach 

Boeing  is  the  prime  development  contractor  for  the  E-3A 
system  and  has  developed  the  airborne  operational  program  which  operates 
on  the  IBM  4 PI  CC-1  (4PI)  computers.  The  airborne  surveillance  radar 
programs  and  the  navigation  programs  have  been  subcontracted  to 
Westinghouse  and  Delco/Northrup,  respectively.  Some  of  the  support 
software  (see  Section  4.3.1  for  the  distinction  between  support  and 
operational  software)  development  was  subcontracted  to  IBM  (e.g.,  the 
4PI  cross-assembler,  simulator,  diagnostics,  and  master  tape  generator) 
and  System  Development  Corporation  (SDC)  (i.e.,  the  JOVIAL  compiler). 
Boeing  has  developed  most  of  the  ground-based  computer  programs  which 
include  the: 

• System  Exercise  & Analysis  Computer  Program,  which 
operates  on  an  IBM  System  370-155  computer  and  generates 
exercise  tapes  and  materials  for  testing  the  operational 
program  and  for  training  personnel.  It  also  reduces  data 
recorded  during  a live  mission  or  test. 

• Mission  Simulator  Program,  which  operates  on  a 4PI 
computer  configuration  similar  to  the  airborne 
configuration . 

• Ground  Support  Computer  Program,  which  operates  on  a 4PI 
and  supports  the  preparation,  maintenance,  and  testing  of 
the  E-3A  data  base. 

• Individual  Positional  Trainer  Program,  which  operates  on 
a 4PI  configuration  and  provides  the  capability  of 
qualifying  E-3A  crew  personnel. 

• Utility  Computer  Programs,  which  support  the  production 
and  maintenance  of  E-3A  programs  that  execute  on  an  IBM 
4PI  and  System  370-155. 

• Surveillance  Radar  Ground  Support  Computer  Programs, 
which  operate  on  an  IBM  System  370-155  and  a radar 
computer. 

3-2.2  Software  Development  and  Maintenance  Facilities 

Boeing  established  an  E-3A  software  development  facility  at 
a plant  in  Seattle,  Washington.  As  of  August  1976,  an  E-3A  Computer 
Program  Ground  Support  Facility  was  being  installed  at  Tinker  AFB,  which 
is  the  E-3A  main  operating  base. 
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The  Boeing  facility  consisted  of  several  development 
laboratories  and  training  centers.  An  Avionics  Integration  Laboratory, 
the  ground  test  bed  for  the  E-3A,  was  used  to  conduct  integration  tests. 
It  basically  was  a mock-up  of  an  E-3A  aircraft  configuration.  A 
Software  Development  Laboratory  was  established  to  develop  and  test  the 
Airborne  Operational  Computer  Programs  and  other  software  that  run  on 
the  4PI  computers. 

An  Engineering  Development  Laboratory  was  used  to  test 
selected  vendor  equipment  prior  to  installation  in  the  Avionics 
Integration  Laboratory.  Another  laboratory  was  established  to  support 
the  Time  Division  Multiple  Access  (TDMA)  development  and  provide 
additional  processing  support  for  E-3A  software  development.  The 
Mission  Simulator  was  used  to  train  mission  crews  and  also  provided  a 
means  to  check  out  the  Airborne  Operational  Computer  Program.  An 
Individual  Positional  Trainer  was  set  up  to  train  individual /crew 
members.  One  IBM  System  370-155  and  the  Mission  Simulator  were  moved 
from  Boeing  to  Tinker  AFB  for  use  by  TAC  and  AFLC  in  maintaining  E-3A 
software . 

3.2.3  Support  Hardware  and  Software 

Two  IBM  System  370-155  computer  systems  were  used  at  Boeing 
for  the  development  of  the  airborne  and  ground  support  programs.  One  of 
the  IBM  System  370-1 55 's  was  provided  as  Government  Furnished  Equipment 
(GFE).  The  other  was  supplied  by  the  contractor. 

The  two  IBM  System  370-155  computers  operated  under  a 
slightly  modified  version  of  the  IBM  operating  system  release  21.7. 

Each  system  was  functionally  equivalent  and  consisted  of  main  memory, 
tape,  disk,  line  printers,  card  reader/punch,  system  console,  paper  tape 
punch,  and  paper  tape  reader.  Boeing  developed  a number  of  tools  in 
addition  to  the  standard  IBM  utilities  to  support  development  of  the 
operational  software. 

Boeing's  philosophy  in  setting  up  the  development 
laboratories  has  been  to  extend  the  operational  hardware  to  accommodate 
software  development.  In  some  cases,  additional  core  was  added  to  run 
on-line  debugging  utilities.  In  other  cases,  special  adapters  were 
designed  to  interface  standard  commercial  peripherals  to  the  4PI 
processor  systems. 

3.2.4  Key  Decisions 

Since  the  system  development  was  contracted  to  a single 
contractor,  only  one  development  facility  needed  to  be  established.  The 
contractor  defined  and  installed  the  required  facility  at  his  plant. 

The  original  contract  called  for  delivery  of  support 
software  necessary  for  maintenance  of  E-3A  software.  This  decision 
should  help  ensure  that  the  Air  Force  can  organically  maintain  the 
system.  It  should  be  noted  that  some  of  the  support  tools  developed  by 


the  contractor  were  not  listed  on  the  original  Contract  Data 
Requirements  List  (CDRL);  however,  since  these  tools  were  developed  with 
Air  Force  money,  they  will  be  delivered  to  the  Air  Force  along  with 
available  commercial  documentation  for  use  at  Tinker  AFB. 

One  major  decision  was  to  change  the  development  support 
computers  from  4PI's  to  IBM  System  370 's.  Engineering  Change  Proposal 
165  recommended  that  IBM  System  370 's  would  be  more  cost  effective  than 
the  4PI  computer  systems  and  would  better  support  some  of  the  large  data 
reduction  processing.  The  change  in  midstream  from  one  support  system 
(4PI)  to  another  (IBM  System  370)  resulted  in  changing  many  of  the 
original  support  software  requirements,  including  the  JOVIAL  compiler. 
The  contractor  thus  developed  some  of  the  IBM  System  370  support 
software  concurrently  with  the  operational  software. 

Responsibility  for  the  development,  maintenance,  and 
modification  of  the  specific  E-3A  computer  programs  was  assigned  to  TAC 
and  AFLC  according  to  their  respective  operational  and  support 
functions.  By  collocating  the  552  AWAC  Wing  with  the  Oklahoma  City  Air 
Logistics  Center  (ALC)  at  Tinker  AFB,  TAC  and  AFLC  will  be  able  to 
jointly  use  the  Computer  Program  Ground  Support  Facility  for  software 
maintenance,  thus  eliminating  the  need  for  separate  TAC  and  AFLC  support 
facilities.  In  order  to  further  enhance  TAC's  organic  software 
maintenance  capability,  nine  TAC  personnel  were  assigned  to  work  as 
programmers  at  Boeing  during  the  software  development  phase.  As  the 
development  phase  neared  completion,  these  personnel  were  reassigned  to 
Tinker  AFB  to  form  the  cadre  of  the  TAC  organic  maintenance  team. 

3.3  NORAD  Cheyenne  Mountain  Complex  Improvement  Program 

The  North  American  Air  Defense  Command  (NORAD)  427M  program  was 
selected  for  study  since  it  includes  a number  of  contractor  and 
Government  development  facilities  and  illustrates  the  use  of  a variety 
of  World  Wide  Military  Command  and  Control  System  (WWMCCS)  and 
commercial  hardware  and  software.  The  427M  system  is  a joint 
development  effort  by  Government  and  contractor  agencies.  The  system 
has  been  in  development  approximately  seven  years.  It  will  replace  the 
425L  (NORAD  Combat  Operation  Center)  and  the  496L  (Space  Defense  Center) 
systems  presently  installed  in  the  NORAD  Cheyenne  Mountain  Complex 
(NCMC).  Portions  of  the  427M  system  were  ready  for  "informal"  testing 
as  of  August  1976. 

The  427M  operational  system  (see  Figure  2)  will  consist  of  three 
segments:  Communications  System  Segment  (CSS),  Core  Processing  System 
(CPS)  segment,  and  Modular  Display  System  (MDS)  segment.  The  CPS 
segment  consists  of  the  Space  Computational  Center  (SCC)  subsystem  and 
the  NORAD  Computer  subsystem  (NCS).  Each  of  the  CPS  subsystems  will 
operate  on  a separate  WWMCCS  H6080  processor.  There  is  also  a backup 
H6080  processor  that  can  be  used  for  testing,  exercising,  NCS  and  SCC 
backup,  and  maintenance. 
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Figure  2.  Simplified  Diagram  of  Major  427M  Operational  Segments 


3.3.1  Acquisition  Approach 


Aerospace  Defense  Command  (ADCOM)  developed  the  NCS 
software.  The  SCC  development  was  contracted  to  SDC.  Aeronutronic  Ford 
Corporation  was  selected  as  the  prime  contractor  for  the  CSS 
development;  however,  SDC  was  subcontracted  to  develop  four  CPCI's  of 
the  CSS.  The  display  subsystem  development  for  the  CPS  was  also 
contracted  to  SDC;  however,  when  another  processor  was  added  to  the  CPS, 
it  was  necessary  to  redesign  the  display  subsystem  (now  designated  as 
the  MDS  segment)  for  a three-processor  system.  This  display  subsystem 
upgrade  was  contracted  to  Aeronutronic  Ford  Corporation  with  the  SDC 
display  software  provided  as  Government  Furnished  Property  (GFP).  The 
MDS  is  a slight  modification  of  the  equipment  and  software  developed  by 
SDC . 


3.3.2  Software  Development  and  Maintenance  Facilities 

Three  facilities  were  used  for  development  of  427M  software: 

• The  Staging  and  Test  Facility  (STATF)  at  Aeronutronic 
Ford  Corporation  was  used  primarily  for  development  of 
the  CSS.  Some  minor  development  was  performed  on  the 
STATF  for  the  MDS  upgrade. 

• Computers  at  the  NCMC  were  used  for  development  of  the 
NCS  portion  of  the  CPS. 

• The  Computer  Programming  Production  Facility  (CPPF)  at 
Ent  AFB  was  used  for  the  development  of  the  SCC  portion 
of  the  CPS.  The  CPPF  was  also  initially  used  for 
development  of  portions  of  the  NCS  software  before  this 
development  was  moved  into  the  NCMC.  Some  of  the 
original  display  subsystem  software  was  also  developed  at 
the  CPPF. 

A Display  and  Programming  Terminal  subsystem  is  being 
developed  and  may  be  used  as  a maintenance  terminal  from  a remote 
location  (possibly  Peterson  AFB)  after  the  CPPF  hardware  is  moved  within 
the  NCMC.  At  the  time  of  the  NORAD  visit  in  August  1976,  the  CPPF  and 
STATF  hardware  had  not  been  moved  into  the  NCMC,  but  the  NCMC  area 
(e.g.,  space,  cabling)  was  being  prepared.  The  final  stages  of 
integration  and  system  test  will  be  performed  in  the  NCMC. 

Aeronutronic  Ford  Corporation  installed  the  STATF  and  was 
responsible  for  running  it.  After  the  STATF  equipment  is  relocated  to 
the  NCMC,  Aeronutronic  Ford  Corporation  will  be  allowed  computer  time  at 
the  NCMC.  ADCOM  will  contract  for  maintenance  of  all  hardware  and 
software  within  the  NCMC. 
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3>3>3  Support  Hardware  and  Software 

Figure  2 depicts  the  major  hardware  components  of  the  427M 
operational  system.  The  STATF  and  CPPF  facilities  included  basically 
the  same  processor  and  peripheral  hardware  for  development  as  that  to  be 
used  in  the  operational  segment  configurations.  Figure  3 illustrates 
the  CPPF  facility  configuration  as  of  April  1976.  Standard  WWMCCS 
support  software  was  used  at  the  CPPF  for  development  of  the  SCC 
including  the  General  Comprehensive  Operating  System  (GCOS).  The  SCC  is 
coded  in  FORTRAN,  COBOL,  JOVIAL,  and  Honeywell's  General  Macro  Assembly 
Program  (GMAP). 

The  CSS  was  developed  at  the  STATF  on  two  commercial 
Honeywell  H6050  processors  using  JOVIAL  (Honeywell  commercial  version) 
and  GMAP.  A special  real-time  executive  was  developed  for  the  CSS 
operational  software  since  the  standard  GCOS  does  not  provide  the 
required  throughput  capabilities.  The  special  executive  is  called  the 
Real-Time  Controller  and  is  loaded  along  with  the  operational  software 
as  a master  job  under  GCOS  control.  The  CSS  was  developed  using  the 
standard  commercial  utilities  provided  by  Honeywell.  Some  special 
support  software  was  developed  to  aid  in  debugging  and  testing.  These 
tools  include  memory  display/change/insert,  buffer  utilization, 
tracking,  snapshot  dump,  and  message  capture  capabilities. 

The  MDS  segment  was  developed  on  Data  General  NOVAs  using 
assembly  language.  Data  General's  Real  Time  Operating  System  Version  2 
has  been  slightly  modified  for  use  as  the  MDS  NOVA  operational 
executive;  however,  the  standard  Data  General  Real  Time  Disk  Operating 
System  and  its  associated  support  were  used  for  development  of  the  MDS. 

The  NCS  is  coded  in  JOVIAL  (WWMCCS  version)  and  GMAP. 
Standard  WWMCCS  support  software  was  used  in  the  development  using  a 
WWMCCS  H6080  processor  within  the  NCMC. 

3. 3.^  Key  Decisions 

The  division  of  the  development  effort  between  Government 
agencies  and  contractors  resulted  in  the  establishment  of  three  large- 
scale  development  facilities.  The  decision  to  use  the  same  hardware  for 
development  as  for  operation  will  reduce  costs  and  will  ease  the 
transition  to  maintenance;  however,  use  of  both  WWMCCS  and  non-WWMCCS 
support  software  and  many  different  types  of  hardware  and  languages 
(JOVIAL,  COBOL,  FORTRAN,  Assembly)  will  complicate  the  maintenance 
effort.  The  ability  to  perform  software  maintenance  using  the  backup 
H6080  processor  is  largely  untested.  The  main  questions  are  how  much 
maintenance  will  be  performed  and  will  enough  time  be  available. 
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Figure  3.  NORAD  (42 7M)  Computer  Program  Production  Facility 
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3.4  SATIN  IV 


The  SATIN  IV  system  was  selected  for  further  analysis  since  it  was 
in  source  selection  in  August  197c  and  thus  provides  an  example  of  how 
requirements  for  SDF's  and  SMF's  can  be  specified. 

3.4.1  Acquisition  Approach 

Development  of  the  operational  software  will  be  divided 
between  an  integration  contractor  and  the  Communications  Computer 
Programming  Center  (CCPC)  at  Tinker  AFB.  The  CCPC  will  develop  the 
application  software.  This  software  will  be  provided  as  GFP  to  the 
system  integration  contractor.  The  integration  contractor  will  develop 
the  operational  executive  software  under  control  of  which  the 
application  software  will  operate.  See  Section  4.3-1  for  the 
distinction  between  operational  and  support  software.  The  contractor 
will  also  install  tne  software  development  and  maintenance  facilities. 

3.4.2  Software  Development  and  Maintenance  Facilities 

A Computer  Program  Development  Facility  will  be  established 
at  the  contractor's  plant  for  development  of  the  executive  software  and 
integration  of  this  software  with  the  application  softwar  A similar 
facility  will  be  located  at  the  CCPC  for  development  of  tae  application 
software.  Following  system  development,  the  Strategic  Air  Command  (SAC) 
will  be  responsible  for  maintenance  of  all  SATIN  IV  operational  and 
support  software  with  the  exception  of  certain  diagnostic  software 
packages.  AFLC  will  maintain  configuration  control  of  the  latter 
packages . 

SAC  will  maintain  SATIN  IV  software  at  a Computer  Program 
Maintenance  Facility  to  be  installed  by  the  contractor  at  Offutt  AFB. 

This  facility  will  be  operational  at  the  time  of  the  system's  Initial 
Operational  Capability  (IOC).  SAC  programmers  and  operators,  trained  by 
the  contractor,  will  man  the  facility. 

3.4.3  Support  Hardware  and  Software 

Since  the  SATIN  IV  program  was  in  source  selection  as  of 
August  1976,  information  about  the  contractors'  proposals  was  sensitive. 

In  addition,  subjects  covered  during  negotiations  could  not  be 
discussed;  hence,  only  the  support  facility  requirements  as  specified  in 
the  Statement  of  Work  (SOW)  and  system  specification  are  described 
below . 

According  to  the  SOW,  the  contractor  will  provide,  install, 
check  out,  test,  and  maintain  at  the  CCPC  sufficient  hardware  and 
software  for  CCPC  to  develop,  produce,  and  test  application  computer 

programs  for  SATIN  IV  [4].  The  contractor  will  keep  the  equipment  and  - 1 

computer  programs  supplied  to  the  CCPC  in  the  same  configuration  as  his 
own  in-plant  equipment  and  computer  programs.  No  further  requirements 
for  the  development  facility  are  specified.  As  stated  in  the  SOW,  the 
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CCPC  development  facility  equipment  could  be  transferred  to  the 
maintenance  facility  at  Offutt  AFB  following  system  turnover  of  program 
management  responsibility. 

A Computer  Program  Maintenance  Facility  will  be  installed  at 
Offutt  AFB  and  will  provide  SAC  the  capability  to  maintain  the 
operational  computer  programs.  Operational  computer  equipment  will  be 
installed  and  checked  out  by  the  contractor.  According  to  the  system 
specification,  the  Computer  Program  Maintenance  Facility  system  segment 
shall  have  sufficient  processors,  peripherals,  and  software  to 
accomplish  the  following  program  maintenance,  development,  and  test 
functions : 

• Assemble,  compile,  debug,  and  test  new  or  modified 
software  modules. 

• Generate  new  or  modified  software  modules  or  systems. 

• Perform  static  and  dynamic  tests  on  new  or  modified 
software  modules. 

• Format  new  software  modules  for  transmission  across  the 
network. 

• Generate  machine-loadable  programs  to  be  delivered  to 
other  processors. 

• Generate  tapes  containing  pre-formatted  messages. 

A standby  processor  associated  with  the  operational  processor  is 
acceptable  for  maintenance.  The  requirements  also  specify  that  the 
system  should  include  a special  line  printer  and  a capability  to  enter 
data  from  a console. 

The  system  specification  further  requires  that  the  system 
and  utility  software  for  the  Computer  Program  Maintenance  Facility  must 
include  at  a minimum: 

• Assembler  (macro) 

• Compilers 

• Loaders  (bootstrap  and  relocatable) 

• Linkage  editor 

• Cross-assembler  and  compiler  (if  support  hardware  is 
different  from  operational  hardware) 

• Program  dump  capabilities  (snapshot,  program,  system) 
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• Software  monitor  (minimum  statistical  data  requirements 
are  specified) 

• Program  trace 

• Off-line  utility  programs  (e.g.,  tape  copy,  merge,  and 
compare) 

• Software  support  library 

• Other  support  programs  (e.g.,  debugging  aids  and 
diagnostics ) 

According  to  the  requirements,  the  maintenance  facility  to 
be  installed  at  Offutt  AFB  need  not  have  the  same  hardware  and  software 
configuration  as  the  CCPC.  Also,  the  hardware  and  software  requirements 
listed  above  apply  to  the  maintenance  facility  - not  to  the  development 
f acility . 

The  source  selection  evaluation  board,  source  selection 
advisory  council,  and  source  selection  authority  are  responsible  for 
determining  whether  the  support  hardware  and  software  proposed  for  the 
Computer  Program  Development  Facility  and  Computer  Program  Maintenance 
Facility  are  adequate.  During  source  selection,  the  Government  will 
negotiate  with  the  contractor  for  delivery  of  the  necessary  support 
tools  and  ensure  that  the  support  hardware  and  software  are  delivered  on 
a schedule  that  enables  the  CCPC  to  develop  and  SAC  to  maintain  the 
system. 

3.4.4  Key  Decisions 

The  decision  to  divide  the  development  effort  between  the 
Air  Force  and  a contractor  resulted  in  the  specification  of  two 
development  facilities.  Since  SAC  rather  than  the  CCPC  will  maintain 
the  software,  a separate  maintenance  facility  was  required.  Each 
facility  will  be  managed,  staffed,  and  operated  by  a separate  agency. 

As  a result,  adequate  planning  and  appropriate  phasing  of  the  transition 
from  development  through  maintenance  is  more  critical  for  these 
facilities  than  for  a facility  that  supports  a system  for  the  total  life 
cycle.  The  SATIN  IV  Computer  Resources  Integrated  Support  Plan  (CRISP) 
identifies  the  organizations  and  their  responsibilities  for  this 
transition.  Configuration  control  of  both  hardware  and  software  among 
the  facilities  is  also  a primary  issue.  The  possibility  of  differing 
maintenance  and  development  support  necessitates  a careful  review  and 
evaluation  of  tools  to  be  delivered  to  SAC  for  maintenance. 

The  decision  to  assign  the  application  software  development 
to  the  CCPC  impacts  how  the  Computer  Program  Development  Facility  there 
will  be  used.  The  SATIN  IV  support  hardware  will  be  housed  in  the  same 
building  as  other  support  hardware.  Space  may  be  critical  and  use  of 
the  equipment  may  be  shared  among  more  than  one  system  development 
effort.  Some  space  has  already  been  allocated  for  SATIN  IV  development. 


34 


Of f-tne-shelf  support  software  is  specified  as  a 
requirement.  This  decision  should  reduce  the  risk  in  software 
development  since  the  support  software  should  not  be  developed 
concurrently  with  the  operational  software.  Higher  support  software 
reliability  should  also  be  expected.  The  identification  in  the  system 
specification  of  specific  types  of  software  support  to  be  delivered  to 
the  Computer  Program  Maintenance  Facility  should  ensure  that,  at  a 
minimum,  certain  tools  will  be  proposed.  The  details  will  be  negotiated 
during  source  selection. 

Many  of  the  SDF  and  SMF  management  issues  have  been 
addressed  in  the  CRISP.  Two  separate  Computer  Program  Development  Plans 
(CPDP's)  will  be  written:  one  by  the  Air  Force  for  application  software 
development  and  the  other  by  the  contractor.  Each  CPDP  will  describe 
the  management  of  the  software  development  effort.  The  Computer 
Resources  Working  Group  (CRWG)  may  coordinate  the  two  plans.  Many  of 
the  key  decisions  affecting  the  SDF's  and  the  SMF,  of  course,  will  be 
made  during  source  selection  and  negotiation. 

3 • 5 TACC  AUTOMATION 

The  first  phase  of  TACC  Automation  (485L),  called  Package  I,  will 
support  TACC  planning,  monitoring,  and  reporting  operations,  primarily 
those  concerned  with  fighter  reconnaissance  and  airlift  missions.  The 
485L  operational  hardware  has  passed  first  article  acceptance  test. 
System  test  is  scheduled  for  1977,  with  an  estimated  operational  date 
for  the  production  systems  in  1982. 

As  of  December  1976,  the  plan  was  to  move  the  first  article 
operational  hardware  to  Bergstrom  AFB  for  system  tests.  TAC  will 
eventually  maintain  TACC  Automation  software  at  Langley  AFB.  There  will 
presumably  be  a transistion  period  after  the  TACC  software  is  delivered 
during  which  the  contractor  programmers  will  assist  TAC  programmers  in 
software  maintenance. 

3-5.1  Acquisition  Approach 

In  1972,  TACC  Automation  hardware  and  support  software  was 
contracted  to  the  Convair  Division  of  the  General  Dynamics  Corporation. 
The  original  contract  requested  the  delivery  of  the  computers  (UNIVAC 
AN/UYK-7's  and  CDC  AN/UYK-25) , display  and  peripheral  equipment,  and 
support  software.  The  First  Article  Hardware  was  to  be  delivered  wicnin 
eighteen  months  to  the  first  article  acceptance  test.  In  addition,  the 
development  facility  hardware  was  to  be  delivered  within  six  months  of 
contract  award  to  Langley  AFB,  Virginia. 

UNIVAC  developed  the  AN/UYK-7  operating  system  and  JOVIAL 
compiler  at  their  plant  in  St.  Paul,  Minnesota.  Initially,  General 
Dynamics  planned  to  use  UNIVAC  as  a subcontractor  to  modify  and  extend 
the  AN/UYK-7  operating  system  software  to  meet  TACC  Automation  software 
requirements.  However  after  prime  contract  award,  General  Dynamics 
encountered  difficulty  in  negotiating  a contract  with  UNIVAC  and  elected 
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to  do  some  of  the  critical  parts  of  the  operating  system  modifications 
and  extensions  themselves  at  their  Ft.  Worth  plant. 

In  1973,  Computer  Sciences  Corporation  (CSC)  received  a 
contract  to  develop  the  Package  I application  software,  with  TAC 
personnel  providing  direct  program  development  support.  By  late  1974, 
CSC  assumed  greater  responsibility  by  also  taking  over  the  support 
software  development  from  General  Dynamics. 

3.5.2  Software  Development  and  Maintenance  Facilities 

The  primary  TACC  Software  Support  Facility  (SSF)  was 
established  at  Langley  AFB  in  the  fall  of  1973,  slightly  behind  the  six- 
month  target.  The  Langley  AFB  SSF  roles  are  to  include  system  test, 
training,  and  software  development. 

Besides  the  facility  at  Langley  AFB,  three  other  facilities 
were  used  for  developing  software  during  the  course  of  the  program. 

These  additional  facilities  included  an  installation  at  UNIVAC,  St. 

Paul,  Minnesota  which  UNIVAC  used  to  develop  part  of  the  support 
software,  particularly  the  JOVIAL  compiler  and  operating  system  for  the 
AN/UYK-7.  Control  Data  Corporation  developed  and  modified  some  of  the 
support  software  for  the  AN/UYK-25  at  their  plant. 

General  Dynamics  in  Ft.  Worth,  Texas,  established  a facility 
which  was  used  for  the  further  development  and  modification  of  the 
UNIVAC  operating  system  as  well  as  for  the  development  of  diagnostic 
programs.  These  additional  facilities  were  not  explicitly  required  by 
the  contracts  and  were  not  deliverable  to  the  Air  Force;  however,  some 
problems  associated  with  them  did  affect  the  progress  of  the  program. 

3.5.3  Support  Hardware  and  Software 

The  requirement  in  the  original  Request  for  Proposal  ( RFP) 
was  that  the  hardware  be  off-the-shelf,  since  the  SSF  hardware  had  to  be 
available  for  program  development  very  soon  (6-9  months)  after  contract 
award.  The  original  RFP  for  the  hardware  contract  also  allowed  the 
hardware  bidders  to  define  the  configuration  of  hardware  to  be  provided 
for  the  Langley  AFB  SSF.  The  requirement  was  that  the  SSF  equipment  be 
"functionally  equivalent"  to  the  first  article  operational  hardware. 

This  requirement  was  established  to  allow  the  contractor  to  propose 
delivery  of  a set  of  compatible  commercial  hardware  for  the  SSF  if 
militarized  hardware  was  proposed  for  the  First  Article  Hardware. 

Some  of  the  hardware  delivered  to  the  Langley  AFB  SSF  was 
prototype  operational  hardware.  Since  the  prototype  hardware  caused 
some  problems,  the  first  article  operational  hardware  was  used  in  place 
of  prototypes  for  software  development  when  it  became  available. 

The  Langley  AFB  SSF  consisted  of  the  following  hardware: 


• Data  Processing  and  Display 
UNIVAC  AN/UYK-7  computer 
Display  consoles  and  group  display 
Primary  mass  storage  (discs) 

Secondary  mass  storage  (tapes) 

• Communications  Processor 

Control  Data  Corporation  (CDC)  AN/UYK-25  computers 
Primary  mass  storage  (discs) 

Secondary  mass  storage  (tapes) 

• Data  Source  Terminal 
CDC  AN/UYK-25  computer 
Display  consoles 

Primary  mass  storage  (discs) 

Secondary  mass  storage  (tape) 

Since  the  SSF  was  originally  installed,  various  additions  have  been 
made.  As  an  example,  the  UNIVAC  9200  support  system  for  the  AN/UYK-7 
was  upgraded  to  a UNIVAC  9300. 

The  TACC  Automation  support  software  was  to  include 
operating  systems  for  all  computers,  JOVIAL  compilers,  assemblers,  and  a 
minimal  set  of  off-the-shelf  support  tools.  The  operating  systems  and 
compilers  transferred  to  CSC  still  required  further  work. 

The  remainder  of  the  support  tools,  the  available  assemblers 
for  AN/UYK-7  and  AN/UYK-25,  utility  tools  (debugging  aids,  etc.),  and 
data  reduction  and  analysis  programs  were  operable  when  delivered.  Some 
additional  support  programs  have  been  developed  by  CSC.  Software 
monitors  and  hardware  diagnostics  are  available  for  all  subsystems. 

3 • 5 . ^ Key  Decisions 

The  acquisition  decision  to  split  the  software  development 
responsibilities  did  not  work  well.  Problems  were  encountered  by 
General  Dynamics  in  providing  the  support  software.  Without  a working 
operating  system  and  compiler  early  in  the  development,  application 
program  development  was  seriously  impeded.  The  split  responsibilities 
dia  cause  some  technical  problems.  Coordination  and  communication 
during  development  were  much  harder  than  if  a single  contractor  had 
developed  all  the  software.  The  split  development  also  resulted  in  the 
facility  becoming  a "shared"  responsibility,  i.e.,  one  contractor 
providing  hardware  and  support  software  and  another  doing  application 
software.  This  situation  has  since  changed. 

Selecting  a SSF  location  removed  from  the  contractor, 
especially  the  hardware  contractor,  created  an  extra  risk.  A facility 
remote  from  both  the  hardware  and  software  contractors'  bases  created 
even  more  difficulties.  The  original  version  of  the  RFP  had  assumed 
that  the  SSF  would  be  established  at  the  application  software 
contractor's  plant.  The  decision  to  locate  the  SSF  at  Langley  AFB  was 
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made  by  the  Office  of  the  Assistant  Secretary  of  the  Air  Force.  The 
reason  given  for  this  change  was  to  provide  a closer  coupling  between 
the  application  software  developers  and  the  user  community  at  TAC.  It 
was  recognized  at  that  time  that  TAC  would  eventually  take  over 
responsiblity  for  the  maintenance  of  the  software,  and  therefore 
locating  the  SSF  at  Langley  AFB  at  the  outset  would  save  the  cost  of 
relocating  the  facility  at  a later  date. 

In  1975,  CSC  claimed  that  the  original  SSF  which  had  been 
installed  at  Langley  AFB  was,  or  would  be,  oversubscribed,  and  thus 
could  not  support  the  software  development  load  which  was  anticipated; 
hence  CSC  and  other  agencies  proposed  that  the  First  Article  Hardware  be 
used  to  augment  the  original  SSF  hardware.  This  use  was  possible 
because  the  First  Article  Hardware  had  completed  its  qualification  test 
program.  The  TACC  Automation  program  has  initiated  development  of  a 
CRISP. 


4.  SOFTWARE  DEVELOPMENT  AND  MAINTENANCE  FACILITY  PLANNING  AND 

ACQUISITION 

Guidelines  for  computer  resource  planning  and  acquisition  are 
generally  outlined  in  AFR  800-14  [ 1].  The  primary  purpose  of  this 
section  is  to  identify  the  key  management  decisions  and  technical  issues 
that  should  be  considered  in  planning  SDF's  and  SMF's.  Section  4.1 
identifies  the  various  Department  of  Defense  (DoD)  and  Air  Force 
policies  and  regulations  that  affect  SDF  and  SMF  planning  and 
acquisition.  The  management  decisions  and  technical  issues  are 
discussed  in  Sections  4.2  and  4.3,  respectively.  Section  4.4  describes 
those  planning  documents  in  which  SDF  and  SMF  requirements  should  be 
specified.  Considerations  in  contracting  for  these  facility  resources 
are  provided  in  Section  4.5.  Finally,  support  hardware  arid  support 
software  items  which  should  be  reviewed  at  PDR  and  CDR  are  summarized  in 
Section  4.6. 

4 . 1 Applicable  Policies  and  Regulations 

This  section  discusses  those  DoD  Directives  (DODD),  DoD 
Instructions  (DODI)  and  military  regulations  that  impact  SDF  and  SMF 
planning  and  acquisition.  On  the  whole  there  is  little  guidance  on  how 
to  plan  and  contract  for  facility  support. 

4.1.1  Department  of  Defense 

The  most  recent  DoD  guidance  impacting  the  management  of 
computer  resources  is  contained  in  DODD  5000.29,  Management  of  Computer 
Resources  in  Major  Defense  Systems  [5].  It  covers  such  areas  as 
configuration  management,  life  cycle  planning,  support  software 
deliverables,  and  government  rights.  Several  other  directives  include 
clauses  that  aptyly  to  the  planning  and  management  of  SDF's  and  SMF's. 

In  particular,  DODI  4105.65,  Acquisition  of  Automatic  Data  Processing 
Computer  Programs  and  Related  Services  [6],  directs  that  there  be  an 
explicit  statement  in  the  purchase  request  of  expected  Government  rights 
in  technical  data,  and  rights  and  responsibilities  regarding  the  use, 
alteration,  maintenance,  and  documentation  of  all  deliverables  including 
computer  programs,  program  test  output,  and  all  data  - during  and  after 
the  period  of  the  contract.  Rights  in  data  are  also  specified  in 
Sections  J and  L of  the  model  contract. 

Consideration  must  also  be  given  to  possible  participation 
in  the  Government-wide  Automatic  Data  Processing  (ADP)  software  sharing 
program  of  Government-owned  or  leased  resources  according  to  DODI 
5030.40,  Government-wide  ADP  Sharing  Program  [7].  DODD  4160.19 .DoD 
Automatic  Data  Processing  Equipment  Reutilization  Program  [8],  directs 
that  ADP  equipment  be  reused  to  the  maximum  extent  practicable  prior  to 
procurement  of  new  equipment  and  facilities.  DODI  5010.21, 

Configuration  Management  Implementation  Guidance  [ 9 ] , provides  guidance 
on  the  implementation  of  DoD  policies  on  configuration  management. 
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DODI  5000.31,  Interim  List  of  DoD  Approved  High  Order 
Programming  Languages  (HOL)  [10],  specifies  high  order  programming 
languages  that  are  approved  by  the  DoD  for  development  of  software  in 
major  defense  acquisition  programs.  These  language  restrictions  have 
significant  impact  on  the  types  of  computer  systems  and  associated 
support  software  that  can  be  selected  for  software  development. 

Procurement  of  facilities  and  related  services  follows 
conventional  practice.  The  Armed  Services  Procurement  Regulations 
( ASPR)  are  the  foundation  for  the  contracting  policies  and  practices  of 
all  the  military  services.  Major  software  procurement  guidance  clauses 
for  software  are  contained  in  ASPR  Section  IX,  Part  5,  "Acquisition  of 
Technical  Data"  [11].  This  part  covers  "rights"  in  data  and  the  form  of 
deliverables.  Since  support  software  is  one  major  resource  of  SDF's  or 
SMF's,  many  of  the  clauses  apply.  Another  guidebook,  An  Air  Force  Guide 
to  Contracting  for  Software  Acquisition  [12],  provides  more  detail  on 
software  clauses  within  the  ASPR. 

4.1.2  Air  Force 

The  AFR  800  series  addresses  computers  and  software  acquired 
as  part  of  a weapons  or  command  and  control  system.  AFR  800-2,  Program 
Management  [ 1 3 ] , states  policy  for  the  management  of  all  Air  Force 
acquisition  programs  which  are  funded  under  research,  development,  test, 
and  engineering  or  procurement  appropriations.  It  implements  DODD 
5000 . 1 , Acquisition  of  Major  Defense  Systems  [14]. 

AFR  800-14,  Volume  II  [1]  consolidates  and  amplifies  Air 
Force  policy  in  other  regulations  that  apply  to  the  acquisition  and 
support  of  computer  resources.  Those  regulations  which  impact  SDF  and 
ShP  planning  cover  such  areas  as  configuration  management,  equipment 
maintenance  policy,  test  and  evaluation,  logistics  support,  and  system 
equipment  turnover.  AFR  800-14  amplifies  policies  in  these  regulations 
to  ensure  that  specific  attention  is  focused  on  the  computer  resource 
aspects  of  system  acquisition.  These  regulations  are  listed  in  AFR  800- 
14  and  should  be  used  in  conjunction  with  AFR  800-14  where  they  apply. 

Chapter  3 of  AFR  800-14,  Volume  II  [1]  provides  guidance  for 
the  planning  of  computer  resources,  including  support  software  and 
hardware.  It  covers  areas  which  impact  SDF  and  SMF  planning  and 
identifies  the  major  planning  documents  as  the: 

• Program  Management  Directive  (PMD) 

• Program  Management  Plan  (PMP) 

• Computer  Resources  Integrated  Support  Plan  (CRISP) 

• Computer  Program  Development  Plan  (CPDP) 

• Operational/Support  Configuration  Management  Procedures 
(0/3  CMP) 
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The  uses  of  these  documents  for  facility  planning  are  discussed  in 
Section  4.4. 

4 . 2 Management  Decisions 

Section  3 identifies  the  key  decisions  involved  in  planning  SDF's 
and  SMF's  for  four  systems  ( E—  3 A , NORAD's,  SATIN  IV,  and  TACC 
Automation).  Several  such  decisions  apply  to  any  system  acquisition. 

The  major  questions  relate  to  defining  facility  requirements.  Figure  4 
depicts  a sequence  of  decisions  and  actions  that  can  be  used  to  define 
these  requirements.  The  letters  at  tne  end  of  the  statements  below 
correspond  to  decision  points  or  actions  on  the  flowchart. 

The  first  steps  are  to  define  what  is  to  be  developed  (A)  and  who 
will  develop  it  (B).  There  are  three  choices  for  development: 

Government  agencies,  contractors  or  some  combination  of  the  two  (see 
Table  1 in  Section  3.1).  This  decision  has  major  impact  on  the  numbers 
and  locations  of  the  facilities. 

For  either  Government  or  contractor  development,  the  next  question 
is  whether  a SDF  is  required.  If  the  system  is  new,  a SDF  should  be 
planned  (C).  If  modifications  are  to  be  made  to  an  existing  system  that 
has  an  3MF,  its  SMF  may  suffice  for  software  development  purposes, 
depending  on  the  extent  of  the  modifications  (D&E). 

Once  the  software  development  tasks  have  been  allocated  between  the 
Government  and  contractor(s)  and  the  need  for  a SDF  established,  each 
agency  should  examine  existing  facilities  to  see  if  they  can  be  utilized 
(F).  AFR  800-14,  Volume  II  [1],  states  that 

"common  and  existing  facilities  will  be  used  whenever 
practicable.  The  size  and  scope  of  the  support  facility  will  be 
based  on  workload  predictions." 

If  the  upgrade  of  an  existing  facility  is  possible  (physically  and 
technically)  and  cost-effective  (G),  the  necessary  hardware  and  software 
improvements,  and  operational  and  management  support,  should  be  planned 
(H).  Otherwise,  the  locations,  tasks,  hardware,  software,  management 
and  operational  support  for  these  SDF(s)  must  be  planned  (I). 

The  maintenance  tasks  for  the  system  should  then  be  defined  (J).  A 
maintenance  facility  is  always  required  if  the  system  is  to  become 
operational.  Who  will  perform  the  maintenance  should  also  be  determined 
(K).  SDF's  are  obvious  candidates  for  SMF's  (L).  According  to  AFR  800- 
14,  a decision  to  provide  organic,  contractor,  or  some  combination  of 
the  two  types  of  support  must  be  based  upon  the  policies  of  AFR  26-2, 

Use  of  Contract  Services  and  Operation  of  Commercial  or  Industrial 
Activities  [15].  This  decision  should  include  consideration  of  such 
factors  as  cost,  system  stability,  interface,  and  test  requirements.  If 
a SDF  is  to  be  utilized  for  maintenance  (P),  its  hardware,  software, 
personnel,  etc.,  must  be  examined  to  determine  whether  it  can  support 
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Figure  4.  Management  Decisions  in  Planning  SDF's  and  SMF's 
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the  maintenance  tasks.  If  the  SDF  is  not  adequate,  upgrading  should  be 
planned  (Q). 

If  the  SDF  is  not  to  become  the  SMF,  other  SDF's  and  SMF's  should 
be  examined  for  possible  use  (M).  The  system  may  be  maintained  at  an 
operational  site.  If  no  SMF  presently  exists  or  is  suitable,  then  the 
locations  and  tasks  of  the  SMF(s)  should  be  defined  (0).  If  the 
locations  of  the  system  operation  change,  SMF  requirements  may  need  to 
be  reexamined . 

If  the  contractor  is  to  provide  either  software  development  or 
maintenance  facilities,  the  Air  Force  must  define  their  requirements  in 
such  a manner  that  they  can  be  incorporated  into  the  RFP  (see  Section 
4.5).  If  the  Government  is  to  provide  the  SDF  or  SMF  support  to  the 
contractor,  the  Air  Force  must  ensure  that  the  support  is  adequate; 
otherwise,  the  contractor  may  be  forced  to  develop  additional  support 
software,  procure  other  equipment  or  slip  the  schedule. 

Planning  for  SDF's  and  SMF's  should  occur  throughout  the  conceptual 
and  validation  phases.  An  Air  Force  program  office  has  a supporting 
role  in  determining  both  the  software  development  and  maintenance 
requirements  during  these  phases.  The  program  office's  primary  goal,  in 
this  regard,  is  to  obtain  the  support  equipment  and  software  necessary 
to  meet  the  needs  of  the  development  and  maintenance  agencies  as  part  of 
the  system  procurement. 

The  CRWG  is  responsible  for  making  many  of  the  major  decisions 
regarding  software  maintenance  and  operational  support.  The  CRWG  is 
initially  chaired  by  the  program  office  and  consists  of  representatives 
from  implementing,  supporting,  and  using  commands.  There  is  a need  for 
well  defined  SMF  requirements  in  the  system  specification  and  SOW. 
Trade-off  studies  should  be  performed  by  the  supporting  and  using 
commands  with  assistance  of  the  CRWG  during  development  of  the  system 
specification.  Estimated  costs  should  be  included  in  a life  cycle  cost 
model  for  the  system. 

The  software  development  management  concepts  and  support  resources 
are  generally  documented  in  the  CPDP,  and  the  maintenance  and  support 
concepts  are  documented  in  the  CRISP.  Section  4.4  further  discusses 
these  planning  documents. 

As  depicted  in  Figure  4,  many  decisions  relate  to  how  support  will 
be  transitioned  from  development  to  maintenance.  This  transition 
requires  careful  planning.  If  maintenance  support  is  not  planned  for 
early  in  acquisition,  critical  support  requirements  may  not  be  included 
within  the  RFP.  If  the  support  hardware  is  not  deliverable,  it  may  be 
unavailable  when  the  Government  takes  over  the  maintenance 
responsibility.  Changing  Government  SDF  configurations  to  suit 
maintenance  needs  in  such  a situation  may  be  impossible  or  prohibitively 
costly . 
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The  determination  as  to  whether  or  not  the  SDF  resources  can  be 
used  for  the  SMF  may  be  dependent  on  the  contractor's  developmental 
approach.  An  analysis  of  the  best  maintenance  approach  following 
development  could  be  performed  by  a contractor  and  included  in  his 
technical  proposal  (e.g.,  CPDP)  if  the  Government  requests  such  an 
analysis  in  the  RFP. 

Hardware  and  software  delivered  to  the  SMF  must  be  adequate  to 
support  the  system.  If  program  funding  levels  must  be  cut,  the  SMF  is 
not  the  place  to  do  so.  Obtaining  more  equipment  and  software  to 
support  an  SMF  after  it  is  transitioned  to  the  using  or  supporting 
commands  is  a difficult  and  time  consuming  task  that  may  have  a direct 
impact  on  the  operational  mission;  therefore,  a SMF  should  be  as 
complete  as  possible  when  delivered  as  part  of  the  total  system. 

Transition  from  development  to  maintenance  is  simplified  if: 

• Only  one  group  (a  specific  contractor  or  the  Government)  is 
responsible  for  both  development  and  maintenance. 

• The  development  facility  becomes  the  maintenance  facility. 

Special  problems  can  be  anticipated  for  maintenance  at  each  of 
several  operational  sites  versus  centralized  maintenance,  especially  if 
a number  of  the  sites  are  remotely  located  from  one  another.  Linder 
these  circumstances: 

• More  support  personnel  are  required. 

• Configuration  control  problems  will  increase  when  program 
changes  are  made  at  each  site. 

• Additional  hardware  will  be  required  at  each  site  to  support 
software  maintenance. 

• More  standardization,  documentation,  and  formal  maintenance 
procedures  may  be  necessary. 

Some  of  the  development  support  software  may  not  be  useable  for 
maintenance  if  different  support  hardware  is  used  for  development  and 
maintenance,  and  the  development  software  is  not  transferable  to  the 
maintenance  computer  systems. 

Prior  to  the  operation  of  either  type  of  facility,  other  important 
questions  must  be  addressed,  including: 

• who  may  use  the  SDF  or  SMF  and  who  decides? 

• Who  establishes  shared  (central)  SDF  or  SMF  operating  schedules 
and  priorities  among  the  various  software  development, 
maintenance,  and  operations  organizations? 
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• Who  controls  access  to  proprietary  support  software? 

• Who  is  responsible  for  support  software  fault  isolation? 

• Who  is  responsible  for  ordering  and  controlling  new  computer 
equipment?  To  whom  does  this  new  equipment  belong? 

4.3  Technical  Issues 

SDF  and  SMF  software  and  hardware  requirements  cannot  be  separated. 
In  many  cases,  available  hardware  dictates  the  types  of  support  software 
that  is  available  or  can  be  developed.  The  remainder  of  this  section 
identifies  the  types  of  support  software  and  support  hardware  that  are 
essential  or  very  useful  and  discusses  special  issues  that  impact  how 
one  should  contract  for  this  support. 

4.3.1  Software 


It  is  necessary  at  this  point  to  distinguish  operational 
software  from  support  software.  Operational  software  is  that  set  of 
programs  which  accomplishes  the  system  functional  processing. 

Operational  software  usually  includes  an  executive  and  application 
programs.  Application  programs  directly  perform  the  system-unique 
functional  tasks  in  support  of  operational  requirements  such  as  tracking 
in  a control  system  like  E-3A,  tabular  or  graphic  display  output,  or 
uata  entry.  The  application  programs  generally  run  under  control  of  an 
executive  or  in  some  cases  a general  purpose  operating  system.  An 
example  of  a general  purpose  operating  system  used  for  controlling 
application  programs  is  GC OS  in  the  Military  Airlift  Command  Integrated 
Management  System  (MACIMS)  (see  Appendix  B).  SATIN  IV  is  contracting 
for  development  of  a special  purpose  executive  under  which  its 
application  programs  will  operate  (see  Section  3.4.1).  There  may  be 
more  than  one  operational  program.  For  example,  in  the  case  of  E-3A, 
some  of  the  operational  programs  operate  aboard  the  aircraft  and  others 
operate  on  the  ground-based  computers. 

Support  software  includes  all  other  programs  used  to  develop 
and  maintain  the  operational  programs.  Examples  of  support  software  are 
compilers,  assemblers,  and  utilities.  A general  purpose  operating 
system  can  be  used  to  control  (that  is  to  load  and  operate)  both 
operational  and  support  software;  therefore,  an  operating  system  can 
fall  into  both  classes,  depending  on  how  it  is  used  within  a given 
system.  Appendix  C discusses  the  most  important  types  of  support 
software  used  in  the  systems  surveyed.  Support  software  can  be 
described  in  terms  of  the  development  activities  it  supports  as  follows: 

• Analysis  & Design:  tools  that  facilitate  the  development 

of  system  requirements  specifications  or  design 
specifications,  and  that  aid  validation  of  program  logic. 
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• Software  Production:  tools  which  actually  process, 

compile,  and  assemble  the  program  code,  and  bind  the 
results  into  executable  modules. 

• Configuration  Control:  tools  that  aid  configuration 

control  and  library  maintenance.  Configuration  control 
involves  those  steps  (manual  or  automated)  necessary  to 
identify  and  document  the  system  elements  (e.g., 
functional,  physical),  control  changes,  and  record 
changes . 

• Test:  tools  that  aid  program  and  system  testing. 

• Hardware  Diagnostics:  tools  used  to  isolate  and  diagnose 

hardware  failures. 

• Performance  Measurement:  tools  that  provide  data  on  the 

system  performance.  These  data  may  be  used  to  locate 
inefficiencies  in  the  system. 

• Documentation : tools  which  help  generate  management 

reports  and  documentation  on  the  system  and  its  parts. 

Verification  and  validation  tools  are  included  in  the  above  list.  These 
tools  will  be  further  discussed  in  the  verification  guidebook  [16]. 

Figure  5 depicts  the  types  of  support  software  required  at 
each  phase  of  the  computer  program  life  cycle.  Examples  of  specific 
software  tools  are  listed  within  each  type. 

4 . 3 . 1 . 1 Host-Resident  vs.  Self-Resident  Support  Software . One 
major  software  development  question  is  whether  the  operational  software 
is  to  be  developed  on  the  same  hardware  configuration  as  that  on  which 
it  will  operate.  Support  software  that  runs  on  one  system,  such  as  an 
IBM  System  370,  to  produce  code  that  operates  on  another  (e.g.,  a Data 
General  NOVA)  is  called  "host-resident".  In  contrast,  "self-resident" 
support  software  runs  on  the  operational  computer  system.  A SDF  or  SMF 
can  include  a combination  of  both  host-resident  and  self-resident 
support  software.  There  are  several  considerations  in  selecting  one  or 
the  other: 

• Many  processors  used  in  command,  control,  and 
communication  systems  have  too  little  core  or 
peripheral  capacity  to  adequately  support  software 
development . 

• Many  minicomputers  (especially  militarized  ones)  have  a 
very  limited  selection  of  off-the-shelf  support 
software;  whereas  large  scale  systems,  such  as  the  IBM 
System  370  have  a large  inventory  of  support  software. 
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optional  depending  on  the  type  of  software  maintenance 


• Use  of  a number  of  smaller,  operational  configurations 
with  expanded  peripheral  support  may  be  cheaper  than  a 
large-scale  host  system  and  may  increase  the  general 
system  availability  and  options  for  debugging  and 
testing . 

• There  are  limitations  to  using  exclusively  host- 
resident  support.  Some  aspects  of  program  operation 
may  be  impossible  to  test  adequately  on  a host  system, 
namely:  timing,  interrupts,  hardware  input  or  output, 
overlay  schemes,  and  interprocessor  communications. 

Host  simulations  of  these  capabilities  must  be 
supplemented  by  tests  on  the  actual  operational 
equipment. 

• Site  maintenance  of  operational  software  is  easier  with 
self-resident  support. 

4. 3. 1.2  Make  or  Buy.  The  trend  in  software  acquisition  has  been 
to  select  and  use  off-the-shelf  support  hardware  and  software. 
Historically,  a high  risk  has  been  associated  with  concurrent 
development  of  operational  and  support  software.  If  proven  support  is 
not  available  at  the  initial  stages  of  development,  the  schedule  can  be 
severely  impacted.  "Off-the-shelf"  is  not  a very  well  defined  term  and 
is  hard  to  establish.  A more  recent  designator  is  "tried-and-true" . 

The  emphasis  is  on  whether  a number  of  parties  have  actually  used  the 
software  and  whether  it  has  proven  reliable.  Use  of  the  "tried-and- 
true"  requirement  might  eliminate  from  consideration  that  support  which 
is  new,  but  not  thoroughly  checked  out  in  a user  environment;  whereas  an 
off-the-shelf  requirement  could  allow  for  such  support. 

Another  possible  designator  is  a "commercial  item  sold  in 
substantial  quantities  to  the  general  public."  Such  a designation  is 
defined  in  the  ASPR  [11],  Section  3-807,  under  pricing  techniques.  As 
defined  in  the  ASPR,  a commercial  item  is  an  item  which  is  regularly 
used  for  other  than  Government  purposes  and  is  sold  or  traded  in  the 
course  of  conducting  normal  business  operations. 

If  any  such  designators  are  used,  they  should  be  defined 
according  to  the  system  needs  in  the  system  specification  or  SOW.  As  an 
example,  one  program  defined  off-the-shelf  to  mean  that  the 

"item  has  been  developed  and  produced  to  military  and/or 
commercial  standards/specifications,  is  readily  available 
for  delivery  from  an  industrial  source,  and  may  be 
procured  without  change  to  satisfy  military 
requirements . " 

4. 3. 1*3  Contractor  vs.  GFP.  In  some  system  acquisitions,  the 
Government  furnishes  the  contractor  with  support  hardware  and  support 
software  to  develop  the  operational  software.  Historically,  there  have 
been  problems  when: 
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• The  GFP  software  developed  by  one  contractor  was  not 
delivered  to  the  Government  in  time  for  use  by  the 
development  contractor. 

• The  GFP  software  did  not  have  adequate  capabilities  and 
the  contractor  had  to  develop  other  support  software. 

When  a contractor  returns  GFP  hardware  and  software  for 
use  by  the  Government  or  another  contractor  in  maintaining  the 
operational  system,  the  following  questions  arise: 

• Does  the  Government  rebenchmark  the  hardware  and 
software? 

9 Has  the  contractor  modified  (on  purpose  or 

inadvertently)  any  of  the  support  hardware  or  software? 

4.3. 1.4  Data  Rights.  Air  Force  rights  to  support  software  and 
related  data  must  be  positively  identified  and  understood  by  all  parties 
to  the  contract.  To  avoid  potentially  serious  problems,  the  Air  Force 
should  contract  for  unlimited  rights  to  obtain,  reproduce  and  use  in  any 
fashion  computer  programs  (including  support  software  and  its 
documentation)  developed  under  the  contract. 

Proprietary  support  software,  firmware,  and  related  data 
can  cause  special  problems.  Firmware  may  be  included  in  off-the-shelf 
support  computer  equipment  or  in  support  equipment  developed  under  the 
contract.  Such  firmware  traditionally  has  proprietary  data  associated 
with  it.  Unless  special  agreements  to  use  such  proprietary  data  are 
negotiated,  the  Government  may  have  absolutely  no  documentation  on  key 
components  of  their  computer  systems. 

It  is  appropriate  at  this  point  to  define  what  is  meant  by 
firmware  since  it  is  a term  that  is  often  misunderstood.  According  to 
DODI  5000.29  [5],  computer  firmware  is  the  logical  code  of  computer 
equipment  which  interprets  the  control  functions  of  that  equipment.  In 
this  context,  firmware  is  a form  of  software,  namely  microcode  (i.e., 
low-level  code)  which  controls  the  sequence  of  events  that  affect 
execution  of  the  native  machine  instructions.  Firmware  always  resides 
in  a control  store  (e.g.,  read-only  memory  or  Programmable  Read-Only 
Memory  (PROM)).  This  definition  is  in  conflict  with  that  specified  in 
MIL-STD-1 52 1 A , Technical  Reviews  and  Audits  for  Systems.  Equipments,  and 
Computer  Programs  [17];  however,  the  DODI  definition  is  more  accurate 
and  will  be  used  for  the  purposes  of  this  guidebook. 

Proprietary  support  software  used  for  computer  program 
development  may  be  unavailable  for  maintenance.  In  this  case,  the 
Government  cannot  maintain  the  system  organically.  Even  if  this  support 
is  made  available  for  Government  use,  proprietary  data  requires  special 
handling  and  storage  within  the  facility  to  restrict  its  access. 

Section  IX  of  the  ASPR  [11]  provides  some  guidance  on  data  rights. 
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4. 3. 1.5  Deliverables  & Schedule  for  Delivery.  The  contract's 
delivery  schedule  and  the  CDRL  should  identify  all  deliverable  support 
equipment,  support  software,  and  documentation  under  the  contract.  If 
any  items  are  not  specified,  the  contractor  is  not  obligated  to  deliver 
them.  Support  software  and  support  hardware  may  be  identified  as 
configuration  items  and  specified  accordingly  in  the  delivery  schedule. 
See  Software  Acquisition  Management  Guidebook:  Statement  of  Work 
Preparation . Appendix  C [18]  for  special  requirements  affecting  delivery 
of  software.  The  form  in  which  support  computer  programs  are  to  be 
provided  (i.e.,  as  source  or  object  code,  as  card  decks  or  magnetic 
tapes)  should  also  be  identified.  If  only  the  object  or  load  module  is 
provided,  maintenance  or  modification  of  the  programs  may  be  impossible. 

A sometimes  unforeseen  problem  occurs  when  a contractor 
develops  originally  unplanned,  special  support  programs  to  aid  in  the 
development  of  operational  software.  In  many  cases,  the  programs  are 
not  documented  and  cannot  be  used  or  altered  by  Air  Force  personnel.  To 
avoid  this  problem  the  contract  should  provide  for  delivery  of  all 
support  software  developed  under  the  contract  with  full  documentation 
and  unlimited  rights. 

If  the  contractor  develops  the  system  with  tools  other 
than  those  delivered,  the  deliverable  tools: 

• May  not  be  adequately  tested. 

• May  not  be  useable,  since  the  contractor  avoided  using 
them. 

* 1 

Obviously,  this  situation  should  be  avoided. 

The  schedule  for  delivery  is  another  area  for  concern.  If 
the  support  is  not  available  when  needed,  the  development  schedule  will 
be  impacted.  The  Air  Force  should  be  cautious  about  deferring  delivery 
of  support  software  in  contracts.  It  is  advisable  to  get  and  use  the 
support  software  early  enough  to  shake  out  any  potential  problems. 

4.3. 1.6  Documentation . An  Air  Force  Guide  to  Software 
Documentation  Requirements  [19]  addresses  the  requirements  for  software 
documentation.  One  common  complaint  expressed  during  the  survey  was 
that  support  software  was  not  documented  well  enough.  Consequently,  in 
some  cases  the  software  could  not  be  adequately  maintained;  in  others, 
there  was  not  enough  information  for  its  operation.  With  the  rather 
large  turnover  of  personnel  in  Air  Force  development  facilities,  good 
documentation  is  essential.  One  area  that  is  sometimes  overlooked  is 
documentation  on  microprogramming  support  software. 

4.3. 1.7  Functional  Demonstrations  or  Benchmarks.  One  RFP  option 
is  to  require  demonstration  of  the  proposed  support  software.  These 
demonstrations  can  provide  invaluable  data  as  to  the  actual  capabilities 
of  the  proposed  systems.  Demonstrations  can  also  be  used  to  establish 
that  support  software  actually  exists  and  that  a particular  support 
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function  operates  as  claimed  (e.g.,  compilation  of  a program  or  creation 
of  a program  library).  Other  tests  can  be  more  standardized  such  as  the 
compiler  validation  test  cases  established  b”  the  National  Bureau  of 
Standards.  Compiler  expansion  ratios  or  compilation  times  can  be 
measured  or  compared  through  benchmark  tests. 

4.3. 1.8  Installation.  Checkout,  and  Acceptance.  The  major 
questions  regarding  installation  and  acceptance  of  support  software  are: 

• Who  will  develop  the  test  plans  and  perform  the  tests? 

• Has  adequate  testing  of  the  software  been  perf^'mned 
prior  to  its  installation? 

• Do  the  acceptance  tests  adequately  test  the  support 
software  and  exercise  those  conditions  that  will  be 
experienced  in  the  facility? 

Support  software  can  be  designated  as  one  or  more  CPCI's 
and  formally  qualified.  This  alternative  is  highly  recommended  in  those 
cases  where  the  software  is  newly  developed  or  largely  untested  within 
industry  and  the  Government. 

There  are  problems  with  acceptance  testing  of  contractor 
provided  free-but-unsupported  software  packages.  Generally  a high  risk 
is  associated  with  their  use.  The  problem  is  sometimes  compounded  when 
a package  does  not  quite  meet  the  user  requirements  and  therefore  must 
be  modified.  Although  acceptance  testing  is  a major  issue  according  to 
the  survey,  it  is  beyond  the  scope  of  this  guidebook  to  fully  discuss 
this  issue. 

4.3. 1.9  Maintenance.  The  main  questions  regarding  support 
software  maintenance  are: 

• Will  the  Air  Force  or  a contractor  be  responsible  for 
maintenance? 

• Which  Air  Force  agency  or  agencies  will  maintain  the 
software? 

• What  types  of  support  software  will  be  maintained  by 
each  agency? 

• Does  the  Air  Force  agency  have  the  resources  necessary 
to  maintain  certain  types  of  support  software  such  as 
compilers  and  operating  systems? 

• Is  the  documentation  good  enough  to  support  organic 
(Air  Force)  maintenance? 

• What  are  the  projected  costs  of  organic  maintenance? 
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Historically,  there  have  been  problems  in  acquiring  and  keeping  Air 
Force  personnel  with  the  training  needed  to  maintain  support  software. 

4.3.2  Hardware 

The  basic  hardware  questions  related  to  SDF's  and  SMF's  are: 

• How  many  development  laboratories  (e.g.,  systems  of 
computer  hardware  and  other  test  equipment)  should  be 
established  within  a SDF  or  SMF? 

• What  tasks  and  workloads  should  each  laboratory  support? 

• What  equipment  configurations  are  necessary  to  support 
the  assigned  tasks? 

• Can  the  support  software  operate  satisfactorily  within 
the  computer  hardware  constraints? 

• Is  the  hardware  reliable  enough  to  adequately  support  all 
of  its  planned  uses? 

• Can  the  hardware  be  expanded  (e.g.,  by  adding  memory 
modules)  to  support  increased  processing  loads  if  these 
occur  at  some  future  point? 

Subject  to  Government  approval,  a contractor  should  have  the  option  of 
ordering  more  hardware  or  sharing  hardware  among  more  than  one  project 
if  hardware  availability  is  a problem.  An  Air  Force  development 
organization  often  has  major  difficulty  in  ordering  more  memory, 
additional  processors,  or  more  peripherals.  Extensive  justification  and 
time  are  involved  in  ordering  such  additional  support;  it  is  essential, 
therefore,  that  hardware  needs  be  anticipated  early  and  accurately. 

A common  complaint  by  both  Air  Force  and  contractor 
development  groups  is  that  more  hardware  should  have  been  ordered  for 
the  initial  stages  of  development.  The  adequacy  of  the  hardware  for 
operation  of  support  software  is  another  issue.  The  host-resident  vs. 
self-resident  support  issues  were  previously  discussed. 

The  following  should  be  considered  when  selecting  (or 
evaluating)  hardware  configurations  for  software  development: 

• Is  the  primary  storage  sufficient  for  operation  of  the 
compilers,  debug  aids,  operating  systems,  and  modelling 
tools,  in  ill  combinations  planned?  Is  this  storage 
sufficient  for  concurrent  operation  and  development  if 
this  mode  is  planned? 

• Is  the  secondary  storage  (disk,  drum,  tape,  etc.) 
adequate  for  operating  system  use,  program  libraries, 
historical  data,  backup  and  restart,  logging  of  messages, 
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utilities,  and  transfer  of  the  software  to  the 
operational  system? 

• Are  there  sufficient  peripheral  devices,  (e.g.,  printers, 
card  readers,  punches,  and  tape  readers)  for  development? 

• If  remote  terminals  (e.g.,  CRT,  batch,  graphic)  are 
required,  is  there  adequate  communications  equipment 
(front-end  processors,  communication  lines,  crypto 
equipment)? 

• Is  an  operational  system  mockup  (e.g.,  E-3A  Avionics 
Integration  Laboratory)  necessary  for  system  testing? 

• Are  the  number  and  types  of  terminals  sufficient  for 
software  development  including: 

- Alphanumeric  CRT  terminals  (with  or  without  printers) 
for  program  entry,  editing,  and  interactive  debugging? 

- Graphic  CRT's  and  associated  hardcopy  output  devices 
for  testing  the  graphics  capabilities  of  tne 
operational  system? 

- Remote  batch  terminals  to  enter  program  data 
and  receive  output? 

- Operational  system  consoles  to  support  testing  and 
training? 

• Is  special  test  equipment  needed  to  check  out  hardware 
prior  to  its  installation? 

• Has  consideration  been  given  to  PROM  burners  and 
associated  microprogramming  support  hardware  if  these  are 
proposed? 


The  software  development  and  maintenance  trade-offs  (e.g., 
contractor  vs.  GFP)  discussed  in  the  previous  section  also  apply  to 
hardware.  Section  3 and  Appendix  B provide  examples  of  how  various 
systems  have  configured  their  SDF 's  and  SMF  s.  The  next  section 
describes  the  planning  documents  in  which  support  hardware  and  software 
requirements  are  specified. 

4 . 4 Planning  Documents 

There  are  four  major  planning  documents  in  which  computer  resource 
requirements,  including  SDF  and  SMF  hardware  and  software  resource 
requirements,  are  specified.  These  are  the: 


PMD 

PMP 
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• CRISP 

• CPDP 

Preliminary  SDF  and  SMF  management  decisions  discussed  in  Section 
4.2  should  be  reflected  as  direction  in  the  PMD  and  PMP.  The  more 
detailed  requirements  and  plans  for  management  and  operation  of  the 
facilities  are  detailed  in  the  CRISP  and  CPDP. 

The  PMD  authorizes  development  of  the  system.  The  following 
directives  that  especially  relate  to  SDF's  and  SMF's  may  be  included  in 
the  PMD,  according  to  AFR  800-14,  Volume  II,  Section  3-6  [1]: 

• "Solicitation  Documents  will  include  explicit  statements 
defining  Air  Force  rights  to  computer  equipment  and  computer 
programs  required  to  operate,  simulate,  and  support  the  system. 
This  includes  computer  program  and  associated  documentation 
(content  and  media)  required  for  maintenance  and  modification." 

• "Supporting  and  using  commands  will  participate  in  the 
requirements  definition,  development,  audits,  test,  and 
maintenance,  and  major  modification  of  computer  programs  and 
equipment. " 

• "Acquisition  of  support  equipment  (such  as  a dynamic  avionics 
integration  laboratory)  and  documentation  will  be  identified 
when  determined  necessary  to  establish  organic  or  competitive 
contractor  support  facilities." 

• "Computer  equipment  reliability,  maintainability  and 
availability  will  be  prime  development  objectives." 

• "Functional  analyses,  trade-off  studies  and  cost  effective 
optimizations  will  be  performed  to  determine  and  define  a low 
risk  development  approach  to  computer  equipment  and  computer 
programs . " 

• "Computer  equipment  and  computer  programs  will  be  identified  as 
configuration  items." 

• "Computer  program  development  and  support  requirements  will  be 
defined  including  the  use  of  Government-funded  equipment  and 
facilities . " 

The  PMP  includes  a plan  for  the  acquisition  management  of  the 
computer  resources  and  identifies  the  support  concepts  based  upon 
studies,  economic  analyses,  and  using  and  supporting  command  inputs. 
Among  the  SDF  and  SMF  requirements  that  can  be  specified  in  the  PMP  are 

• Computer  program  data  rights. 

• Simulation,  integration  and  other  special  support. 
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• Configuration  management  concepts. 

According  to  AFR  800-14,  Volume  II,  Section  3-8  [1],  the  CRISP 
identifies  computer  resources  necessary  to  support  computer  programs 
after  transfer  of  program  management  responsibility  and  system  turnover. 
It  identifies  the  organizations,  their  relationships  and  their 
responsibilities,  and  serves  as  the  basic  agreement  between  supporting 
and  using  commands  following  system  turnover.  Qualified  support 
personnel  and  their  training  requirements  are  also  identified  in  the 
CRISP. 

The  CRISP  also  includes  plans  for  configuration  management  of 
computer  programs  including  configuration  control  responsibilities 
during  the  deployment  phase.  An  0/S  CMP  can  be  used  to  further  detail 
configuration  management  procedures  outlined  in  the  CRISP. 

The  SATIN  IV  CRISP  provides  an  example  of  how  these  requirements 
can  be  specified.  It  covers  such  areas  as: 

• Organizations  responsible  for  management  and  operation  of  the 
Government  facilities  and  their  relationships. 

• Security  controls. 

• Personnel  and  training  requirements. 

• Software  support  organization  structure. 

The  AWACS  Life  Cycle  Computer  Program  Management  Plan  basically 
serves  as  the  CRISP  for  E-3A.  It: 

• Describes  the  operational  facilities. 

• Discusses  the  joint  utilization  concept  (TAC,  AFLC,  Air  Training 
Command  (ATC)). 

• Identifies  the  support  and  maintenance  responsibilities  for  each 
computer  program  (support  or  operational). 

• Describes  the  TAC  support  organizational  structure 
responsibilities. 

• Addresses  personnel  training. 

• Lists  manpower  requirements  and  schedules. 

The  CPDP  is  the  major  plan  that  addresses  SDF  requirements.  A CPDP 
mav  be  prepared  by  each  prime  or  associate  contractor  and  approved  by 
the  implementing  command  if  the  development  is  contracted;  otherwise  the 
program  office  must  prepare  the  CPDP.  Among  the  CPDP  items  listed  in 
AFR  800-14,  Volume  II  [1]  which  impact  SDF  requirements  are: 


• "The  organization,  responsibilities  and  structure  of  the 
group(s)  that  will  be  designing,  producing,  and  testing  all 
computer  programs." 

• "The  methodology  for  insuring  satisfactory  design  and  testing, 
including  quality  assurance." 

• "The  resources  required  to  support  the  development,  and  test  of 
computer  programs.  Special  simulation,  data  reduction  or 
utility  tools  that  are  planned  for  use  in  development  of 
computer  programs  should  be  identified." 

• "Th.e  methods  and  procedures  for  collecting,  analyzing, 
monitoring,  and  reporting  on  the  timing  of  time  critical 
computer  programs." 

• "The  management  of  computer  program  development  masters,  data 
base,  and  associated  documentation  including  its  relationship  to 
the  configuration  management  plan." 

• "The  approach  for  developing  computer  program  documentation." 

• "Training  requirements  and  associated  equipment  for  the 
deployment  phase." 

• "Security  controls  and  requirements." 

• "Simulation  techniques  ar.d  tasks." 

4 . 5 Contracting 

Another  guidebook  [12],  covers  contracting  from  early  procurement 
planning  through  the  source  selection  process  to  the  management  of  the 
contractor's  work.  This  section  highlights  the  contractual  aspects  of 
SDF's  and  SMF's  to  consider  in  these  phases. 

The  procurement  plan  describes  and  justifies  the  procurement 
approach.  It  is  based  on  technical  assessment  of  the  operational  and 
support  requirements,  the  management  decisions  of  the  Air  Force  program 
office  director,  and  inputs  from  the  contracting  office.  The  SDF  or  SMF 
management  decisions  discussed  in  Section  4.2  should,  therefore,  be 
reflected  in  the  procurement  plan. 

The  RFP  invites  contractors  to  submit  proposals  and  includes  the 
following: 

• Model  contract  including  a schedule 

• SOW 

• CDRL 

• Specifications 

• Instructions  to  offerers 
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The  RFP  is  discussed  in  greater  detail  in  the  SOW  guidebook  [18]. 

The  SOW  is  that  part  of  an  RFP  that  describes  the  scope  of  work  the 
Government  wants  done  by  the  selected  contractor.  SDF  and  SMF 
requirements  including  support  programs,  equipment  and  documentation 
should  be  specified  in  the  SOW  and  system  specification,  and  itemized  as 
deliverables  in  the  CDRL  and  delivery  schedule.  The  SOW  should  be 
cross-checked  against  the  CRISP  for  consistency  or  vice  versa  if  the  SOW 
is  prepared  first.  Support  software  deliverables  may  be  identified  as 
CPCI's. 

If  a facility  is  to  be  constructed,  a facility  development 
specification  (referred  to  as  a type  B4  specification)  may  need  to  be 
developed  (see  MIL-STD-490,  Specification  Practices  [20],  Appendix  V). 
This  specification  covers  such  facility  requirements  as  civil, 
architectural,  structural,  mechanical,  and  electrical. 


The  JTIDS/ASIT  (see  Appendix  B)  and  SATIN  IV  system  acquisitions 
illustrate  how  support  requirements  can  be  incorporated  into  the  RFP. 
The  RFP  may  request  the  contractor,  where  appropriate,  to  submit  a CPDP 
with  his  proposal  (e.g.,  ASIT  procurement).  This  procedure  allows  the 
Air  Force  to  better  evaluate  the  contractor's  capability  to  perform  and 
manage  software  development  within  the  specified  support  resources. 


Following  receipt  of  the  proposals,  the  actual  evaluation  of  the 
proposal  and  selection  of  the  contractor  is  performed  by  a source 
selection  organization.  Evaluation  criteria  are  established  prior  to 
receipt  of  the  proposals.  The  RFP  indicates  the  major  criteria  and 
tneir  order  of  priority.  Common  areas  of  evaluation  are  technical, 
cost,  and  management.  F.ach  area  is  further  broken  down  into  items  and 
items  into  factors.  Standards  (i.e.,  specific  evaluation  criteria)  are 
developed  for  factors. 


It  is  important  that  criteria  be  established  to  evaluate  the 
support  software  and  hardware  proposed  if  requirements  for  these  exist, 
whether  the  support  requirements  are  reflected  as  separate  items  or 
factors  depends  on  their  relative  importance  in  the  software 
acquisition.  In  either  case,  the  criteria  are  derived  from  RFP 
requirement  statements  (i.e.,  they  must  be  traceable).  The  proper 
preparation  of  these  standards  has  major  impact  as  to: 


• whether  significant  parts  of  the  support  requirements  are 
evaluated . 

• How  much  impact  the  support  requirements  have  on  the  total 
system  evaluation. 

The  JTIDS/ASIT  source  selection  also  included  a benchmark  (i.e.,  a 
functional  demonstration)  of  the  operational  hardware  and  support 
software  proposed  by  each  contractor. 
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In  the  next  phase  of  source  selection,  contractors  are  asked  to 
clarify  the  ambiguous  aspects  of  their  proposal.  It  is  important  in  the 
area  of  SDF's  and  SHF's  to  clearly  understand  such  items  as: 

• Number  of  facilities 

• Their  locations 

• Hardware  configurations 

• Specific  versions  or  releases  of  the  support  software 

• Government  rights 

• Deliverables  and  non-deliverables 

• Newly  developed  vs.  off-the-shelf  items 

The  Government  then  enters  into  negotiations.  Negotiations  are  a 
crucial  step  in  the  acquisition  process.  If  the  Government  does  not 
negotiate  the  essential  SDF  and  SHF  support  items,  the  whole  program  may 
be  in  jeopardy.  However,  support  that  is  unnecessary  should  be  avoided. 
Again,  the  deliverables,  schedules  and  data  rights  should  be  clearly 
understood  between  both  parties. 

Hanagement  of  the  contract  begins  after  the  contract  is  negotiated 
and  signed  . Contract  changes  can  be  instituted  either  by  a supplemental 
agreement  (mutual  agreement  between  the  Air  Force  and  contractor)  or  by 
a change  order  (unilateral  action  by  Air  Force).  Engineering  change 
proposals  can  be  used  to  change  support  hardware  and  software 
specifications  in  a contract. 

4.6  Technical  Reviews 

During  PDR's  and  CDR's,  computer  program  development  facility 
(i.e.,  referred  to  as  an  SDF  in  this  guidebook)  support  software  and 
support  equipment  must  be  reviewed.  MIL-STD-.1521A  [17]  lists  several 
items  that  should  be  checked.  In  particular,  Sections  3 0.22  and  30.23 
indicate  that  the  availability  and  planned  utilization  of  any  computer 
program  development  facility  should  be  addressed  at  PDR.  The  contractor 
should  provide  information  on  the  design  of  support  programs  that  are 
produced  to  aid  the  development  of  the  CPCI(s) . In  addition,  he  should 
identify  any  special  simulation,  data  reduction  or  other  software  tools 
that  are  not  deliverable  under  terms  of  the  contract,  but  which  are 
planned  for  use  during  program  development.  MIL-STD-1521A  recommends 
that  the  following  steps  be  performed  when  reviewing  any  support 
equipment . 

• Review  considerations  that  are  applicable  to  support  hardware 
and  support  computer  program  Cl's  (i.e.,  the  same  reviews  should 
be  performed  for  support  hardware  and  computer  program  Cl's  as 
are  performed  for  other  Cl's). 
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• Verify  that  adequate  trade-offs  have  been  performed  for  built-in 
test  equipment  vs.  separate  test  equipment. 

• Verify  that  designated  GFE  is  planned  to  be  used  to  the  maximum 
extent  possible. 

• Review  progress  of  long-lead  time  support  equipment  items. 

• Review  progress  toward  determining  requirements  for 
installation,  checkout,  and  test  support. 

• Review  reliability  and  maintainability  requirements. 

• Identify  logistic  support  requirements. 

• Review  calibration  requirements. 

• Identify  technical  manuals  and  data  availability  for  support 
equipment . 

• Verify  compatibility  of  proposed  equipment  with  the  system 
maintenance  concept. 

At  CDR,  the  reviews  listed  in  MIL-STD- 1 521 A [17],  Sections  40.1.3-1 
through  40.1.3.3,  that  are  applicable  to  support  hardware  and  support 
software  should  be  performed.  MIL-STD-1 521 A also  lists  special  checks 
that  are  tc  be  made  on  firmware  and  microprogramming  support  tools.  In 
particular,  the  contractor  should  provide  descriptions  and  status  for 
any  microprogramming  development  tools  such  as  self-resident  assemblers, 
loaders,  debugging  routines,  and  executives;  and  host-resident 
assemblers,  compilers,  and  instruction  simulators. 

At  either  PDR  or  CDR,  the  technical  issues  raised  in  Section  4.3 
and  potential  problems  listed  in  Section  5 of  this  guidebook  should  be 
addressed  in  order  to  determine  the  adequacy  of  any  support  equipment  or 
support  software  planned  by  the  contractor. 

f . 


POTENTIAL  PROBLEMS  AND  RECOMMENDATIONS 


5. 

Certain  problems  in  the  planning,  acquisition,  and  operation  of 
SDF's  and  SMF's  were  discussed  in  Section  3.  Various  people  interviewed 
during  the  facility  survey  also  related  "lessons  learned"  from  their 
past  facility  experiences.  The  following  list  summarizes  some  of  the 
common  problems  and  includes  recommendations  for  their  solutions. 

• System  development  and  maintenance  responsibilities  were  too 
fragmented . 

Recommendations : Avoid  separation  of  the  software  development 

effort  among  the  Government  and  contractors.  Different  portions 
of  the  operational  software  are  sometimes  developed  or 
maintained  by  various  contractor  and  Government  agencies.  For 
example,  executive  software  could  be  developed  and  supported 
separately  from  the  application  software.  This  division 
significantly  complicates  the  management  process,  increases  the 
SDF  resource  requirements,  and  aggravates  configuration  control 
problems . 

• The  SDF's  did  not  provide  the  required  capabilities  for  software 
development. 

Recommendations : Establish  SDF  requirements  early  after  careful 

analysis  of  the  proposed  tasks  and  uses.  Make  sure  these 
requirements  are  incorporated  into  the  PMD,  PMP,  CRISP,  CPDP, 
and  RFP.  Carefully  develop  source  selection  evaluation  criteria 
to  ensure  that  critical  support  areas  are  evaluated.  Negotiate 
for  that  support  that  is  essential. 

• The  support  hardware  or  software  was  not  reliable  because  it  was 
newly  developed. 

Recommendations : Use  well  tested,  off-the-shelf  hardware  and 

software  for  development  wherever  possible.  If  new  or  modified 
support  software  or  equipment  is  required,  allow  enough  time  for 
its  development,  testing,  and  documentation  before  its  use.  If 
the  contractor  has  developed  a support  tool  for  subsequent 
delivery  to  the  Air  Force,  ensure  that  he  has  actually  used  the 
support  tool  in  tne  development  of  the  operational  software  and 
has  adequately  tested  it  before  such  usage. 

• The  support  tools  were  not  available  when  they  were  needed  in 
the  early  stages  of  development. 

Recommendations : Schedule  delivery  of  the  support  software  and 

hardware  so  that  they  are  available  early  in  the  development. 
Allow  enough  time  for  check  out  and  shake  down  of  this  support. 
Do  not  develop  support  tools  concurrent  with  operational 
software  whose  development  they  will  support. 
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• The  support  computer  hardware  was  not  available  early  enough  to 
adequately  check  out  the  support  software. 

Recommendations : Ensure  that  support  computer  hardware  is 

delivered  on  a schedule  that  allows  it  to  be  used  to  test  the 
support  software.  Use  previously  well  tested  support  software 
where  feasible  to  minimize  the  need  for  such  testing. 

• The  SMF  did  not  have  adequate  support  hardware  and  software. 

Recommendations : Carefully  examine  the  types  of  maintenance 

support  required  (e.g.r  simple  program  version  releases  or  major 
modifications)  and  the  anticipated  workloads.  Ensure  that  this 
support  is  delivered.  Consider  the  use  of  an  integrated  support 
facility  to  maintain  both  the  operational  and  support  hardware 
and  software  if  total  system  maintenance  is  the  responsibility 
of  an  Air  Force  agency  (e.g.,  AFLC) . 

• The  support  software  could  not  be  maintained  organically  (in- 
house)  . 

Recommendations:  Ensure  that  the  form  of  the  delivered  software 

includes  source  code.  Require  adequate  documentation,  including 
source  code  listings.  Plan  for  assignment  and  ti dining  of  the 
proper  numbers  of  maintenance  personnel  with  appropriate 
backgrounds  before  they  will  be  needed.  Use  standard 
maintenance  support  by  vendors  wherever  possible. 

• There  was  poor  documentation  on  the  support  software. 

Recommendations : Ensure  that  well  commented  source  listings, 

flowcharts , and  narratives  are  delivered  with  support  tools. 

Make  sure  there  is  adequate  information  (e.g.,  user's  manual) 
for  use  of  any  support  tool.  In  general,  standard  vendor 
manuals  should  be  available  for  any  off-the-shelf  support. 

Review  these  to  assure  their  adequacy.  Ensure  that  there  is 
adequate  documentation  on  all  support  hardware.  Also  see  the 
guidebook  on  software  documentation  [19]. 

• There  was  not  enough  hardware  for  development. 

Recommendations : Plan  enough  hardware  (e.g.,  memory,  secondary 

storage)  to  support  development  based  on  a thorough  analysis  of 
all  anticipated  uses  of  the  hardware  and  support  software 
requirements.  This  analysis  is  particularly  important  where  an 
operational  minicomputer  configuration  is  expanded  to  support 
software  development. 

• The  hardware  did  not  come  bundled  with  adequate  support 
software . 
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Recommendations : If  a minicomputer  is  selected  as  the 

development  system,  carefully  examine  the  available  support 
software  for  adequacy.  The  operating  system  and  other  support 
software  advertized  for  a particular  vendor's  minicomputer 
system  should  be  examined  to  see  if  it  really  exists,  is 
reliable,  and  provides  the  necessary  capabilities.  Some 
militarized  minicomputers  have  a commercial  counterpart  (often 
less  expensive)  that  comes  bundled  with  a large  complement  of 
support  software.  This  software  can  also  operate  on  the 
militarized  version.  Consider  the  use  of  host-resident  support 
where  the  capabilities  of  the  minicomputer  (e.g.,  peripherals) 
are  limited.  Also  consider  the  use  of  hardware  adapters  that 
interface  commercially  available  peripherals  to  militarized 
processors.  If  these  measures  do  not  suffice,  plan  development 
and  early  delivery  of  supplementary  support  software. 

• Hardware  diagnostics  were  lacking. 

Recommendations : This  requirement  is  often  overlooked. 

Development  of  software  is  a difficult  enough  task  without 
trying  to  resolve  whether  the  errors  are  hardware  or  software 
related.  Hake  sure  these  tools  are  available  and  deliverable. 

• Standard  procedures  and  programs  for  acceptance  testing  of  the 
support  system  were  not  adequate. 

Recommendations : Ensure  that  acceptance  test  procedures  and 

plans  are  available  and  that  the  acceptance  test  tools  are 
adequate . 

• Test  tools  were  inadequate. 

Recommendations : PQT,  FQT,  System  DT&E,  and  OT&E  are  crucial 

steps  in  software  development.  Carefully  examine  the  test 
requirements  and  ensure  that  the  right  tools  are  contracted  for. 

• There  was  not  enough  physical  space  in  the  facility.  (This 
problem  was  very  common.) 

Recommendations : Plan  enough  space  in  the  SDF  or  SMF  for  the 

hardware,  libraries,  programmer  work  areas,  and  maintenance 
spares,  considering  all  concurrent  uses. 

• The  operating  system  had  to  be  modified  in  order  to  meet  the 
user  requiremencs . 

Recommendations : Carefully  examine  operating  system 

requirements  for  the  support  system.  Avoid  modification  of  any 
operating  system  wherever  possible.  The  decision  to  modify  an 
executive  or  operating  system  must  be  heavily  weighed  against 
all  potential  consequences.  In  particular,  maintenance  of  a 
modified  operating  system  can  be  extremely  costly  over  the  total 


62 


system  life  cycle.  A survey  of  off-the-shelf  operating  systems 
should  be  made  to  determine  if  any  existing  systems  are 
adequate.  If  an  operating  system  is  to  be  modified,  allow 
enough  time  and  effort  for  the  changes  to  be  made  and  tested 
before  its  use.  The  design,  documentation,  and  integration  of 
such  changes  rihist  be  carefully  controlled. 

• The  compiler  was  not  adequate. 

Recommendations : Carefully  examine  compiler  requirements. 

Compiler  limitations  can  severely  impact  the  development  effort. 
Avoid  development  of  a new, compiler  concurrent  with  development 
of  the  operational  software. 
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BRIEF  DESCRIPTION  OF  AIR  FORCE  SYSTEMS  INCLUDED  IN  SURVEY 


E-4  (AABNCP)  - Advanced  Airborne  Command  Post 

AABNCP  will  provide  a survivable  command  post  capability  for  SAC 
and  the  Joint  Chiefs  of  Staff.  The  Block  I system  will  basically 
include  an  AUTODIN  terminal  capability  aboard  the  airplane. 

The  AABNCP  functions  include: 

• Situation  monitoring 

• Tactical  warning  and  attack  assessment 

• Force  status  monitoring 

• Force  and  planning  execution  monitoring 

• Civilian  responsibility  support 

• Negotiation  and  termination 

The^e  are  plans  for  six  E-4  airplanes  and  one  ground  facility  at 
Offutt  AFB . 

AFSATCOM  I - Air  Force  Satellite  Communications  System 

The  AFSATCOM  system  will  provide  satellite  communications  to 
satisfy  high  priority  Air  Force  requirements  for  operational 
command  and  control  of  forces  on  a worldwide  basis.  Some  of  the 
communications  functions  satisfied  by  AFSATCOM  include  presidential 
communications,  message  transmission  to  Single  Integrated 
Operational  Plan  forces,  force  control,  and  airborne  command  post 
intercommun icat ions . 

E-3A  ( AWAC3 ) - Airborne  Warning  and  Control  System 

E-3A  will  provide  airborne  surveillance,  command  and  control,  and 
communication  capabilities  with  a complex  and  closely  integrated 
hardware  and  software  system.  It  presently  includes  three  E-3A 
test  aircraft.  Eventually  up  to  3^  aircraft  may  be  produced. 

COBRA  DANE 

COBRA  DANE  is  a large  L-band  phased  array  radar  system  located  at 
Shemya  AFB,  Alaska.  It  is  being  procured  by  ESD  for  use  by  the 
Foreign  Technology  Division  and  ADCOM.  Its  missions  are  collection 
and  dissemination  of  intelligence  data  on  Soviet  ballistic  missile 
test  firings,  detection  and  warning  of  missile  firings  impacting  in 
the  continental  United  States,  and  collection  and  dissemination  of 
data  on  earth  satellite  vehicles. 
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COMBAT  GRANDE  - Semi-Automated  Spanish  Air  Defense  System 


Under  a 1970  Agreement  of  Friendship  and  Cooperation  between  Spain 
and  the  Unitea  States,  the  COMBAT  GRANDE  program  was  established  to 
modernize  and  partially  automate  the  existing  Spanish  Aircraft 
Control  and  Warning  system.  The  planned  air  defense  network 
provides  for  centralized  data  processing  and  command  and  control 
functions,  including  netting  of  radar  and  radio  sites  and  a 
significantly  upgraded  microwave  communications  system,  all  built 
around  the  existing  Aircraft  Control  and  Warning  system.  COMBAT 
GRANDE  will  also  interface  digitally  with  the  French  Air  Defense 
System. 

CONUS  OTH-6  PRS  - Continental  United  States  Over-the-Horizon  Backscatter 

Prototype  Radar  System 

The  CONUS  OTH-B  PRS  program  is  developing  a prototype  radar  system 
to  provide  radar  surveillance,  tracking  and  identification  of 
aircraft  at  extended  ranges  from  a site  located  in  the  Northeast 
continental  United  States.  As  each  aircraft  is  detected  by  the 
prototype  radar  system  and  its  track  established,  a comparison  of 
flight  characteristics  (heading,  speed,  position,  etc.)  will  be 
made  with  available  flight  plan  and  positional  data  to  achieve 
track  correlation  and  aircraft  identif ication . 

JS3  - Joint  Surveillance  System 

The  J5S  program  was  established  to  provide  surveillance  and 
peacetime  control  of  designated  airspace,  including  the  CONUS, 
Alaska  and  Canada.  The  system  is  to  replace  existing  SAGE  and  BUIC 
surveillance  systems.  Although  intended  for  peacetime 
surveillance,  JSS  would  serve  in  a transitional  role  during  wartime 
until  E-3A's  took  over.  The  Alaska  system  will  have  some  tactical 
and  Electronic  Counter  Counter  Measures  (ECCM)  capability.  The 
Canadian  system  will  have  a limited  war  capability,  including  ECCM 
and  automatic  interceptor  vectoring. 

JTIPS/ASIT  - Joint  Tactical  Information  Distribution  Svstem/Adaptable 

Surface  Interface  Terminal 


JTIDS  is  an  advanced  communications  system  that  will  provide 
integrated  communications,  navigation  and  identification  for  the 
Army,  Navy,  Air  Force,  and  Marine  Corps.  Surface  subscribers 
(e.g.,  mobile  ground  and  ship)  and  aircraft  elements  will  be 
supplied  with  JTIDS  terminals  and  will  transfer  combat  data  over  a 
high  capacity,  jam  resistant,  secure  information  distribution 
network.  ASIT  will  incorporate  the  JTIDS  capability  into  existing 
surface  tactical  surveillance  and  command  and  control  systems  by 
adding  a terminal  that  provides  a "transparent"  interface  to  the 
surface  subscriber  systems. 
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MACIMS  - Military  Airlift  Command  Integrated  Management  System 


MACIMS  provides  both  operational  and  management  information 
processing  support  for  the  Military  Airlift  Command  (MAC)  airlift 
missions.  The  present  system  consists  of  approximately  16 
subsystems  which  support: 


Mission  management 
Transportation  management 
Airframe  management 

Airlift  services  industrial  fund  management 
Aircrew  management 
Planning  management 


NCMC  Improvement  Program  (M27M) 


The  NCMC  Improvement  Program,  427M,  interfaces  the  NCMC  with  world- 
wide command,  control,  and  communication  elements. 


PAVE  PANS  - Phased  Array  Warning  System 


PAVE  PAWS  is  a system  that  will  employ  two  long-range  coastal 
radars  to  detect  and  track  submarine  launched  ballistic  missiles, 
and  to  support  the  USAF  spacetrack  system  with  earth  satellite 
vehicle  surveillance,  tracking,  and  radar  space  object 
identif ication . 


SATIN  IV  - SAC  Automated  Total  Information  Network 


SATIN  IV  will  provide  data  communications  to  support  the  worldwide 
record  data  command,  control,  and  communication  requirements  of  the 
National  Command  Authority  and  SAC.  The  system  will  replace  the 
hardware  of  the  SAC  Automated  Command  Control  System  and  the 
command  and  control  functions  of  SATIN  I.  It  will  be  a SAC 
subsystem  of  WWMCCS. 


TACC  AUTOMATION  - Tactical  Air  Control  Center  Automation  (485L) 


The  initial  TACC  Automation  Program  consists  of  additions  and 
modifications  of  equipment  and  facilities  developed  for  the 
Tactical  Air  Control  System  under  the  407L  program.  The  objective 
of  these  additions  and  modifications  i3  to  improve  operational 
force  management,  planning,  and  control  of  tactical  air  operations. 


TRI-TAC  - Tactical  Communication  Control  Facilities  (TCCF) 


The  TRI-TAC  Tactical  Communication  Control  Facilities  program  is 
developing  a ''family"  of  tactical  facilities  to  perform  such 
functions  as  technical  control  of  communications  facilities, 
dynamic  control  of  communications  systems,  and  automated  support 
for  broad  system  level  planning  and  engineering. 
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APPENDIX  B 


AIR  FORCE  SOFTWARE  DEVELOPMENT  AND  MAINTENANCE  FACILITY  SURVEY  DATA 


E-4  ( AABNCP)  Facilities 

Boeing  has  established  a SDF  at  their  plant  for  development  of  the 
application  software.  Another  SDF  has  been  set  up  by  Burroughs  to  aid 
in  debugging  communication  processor  firmware  and  diagnostic  software. 
Neither  facility  is  deliverable,  but  the  Government  has  use  of  available 
software  through  special  data  rights.  Plans  for  software  maintenance 
following  system  turnover  have  not  been  finalized.  The  SDF  at  Burroughs 
will  be  phased  out  after  delivery  of  the  communications  processor 
system.  System  tests  will  be  performed  using  an  operational  E-4 
aircraft  configuration. 

The  support  software  that  Burroughs  supplied  for  the  Boeing  SDF 
includes : 

• Operating  system 

• Assembler 

• Link  editor 

• Text  editor 

• Library  editor 

• Maintenance  and  diagnostic  support 

Boeing  built  support  software  includes: 

• System  test  operational  program 

• Journal  tape  print  program 

• System  tape  generation  program 

• Tape  duplication  program 

• AUTODIN  simulator  program 

A specialized  product  from  Burroughs  with  the  "D  machine" 
architecture  is  used  as  the  Central  Processing  Unit  (CPU).  The  CPU  can 
be  used  to  emulate  the  architecture  of  the  other  computers.  It  runs  as 
a stack-oriented  machine  for  software  development  and  emulates  the  E-4 
communications  processor  for  software  checkout.  The  mode  is  selected 
by  loading  the  appropriate  microprogram  into  the  control  memory. 

AFSATCOM  I Facilities 

Collins  Radio  Group  was  awarded  the  develoment  contract  for 
terminal  hardware  and  software.  They  chose  the  Rolm  1601  as  the 
terminal  processor.  The  terminal  embodies  a dual  processor  and 
considerable  special  hardware,  including  encryption  devices,  special 
input  and  output  interfaces,  and  modems.  Collins  developed  the 
operational  software  on  an  in-plant  UNIVAC  1108,  using  a NOVA  cross- 
assembler.  An  executive  plus  application  programs  were  tested  on  in- 
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plant  developmental  terminal  equipment.  Collins  has  comp] eted  initial 
operational  tests  of  Model  I software. 

An  AFSATCOM  SMF  is  planned  at  CCPC,  Tinker  AFB,  with  capability  for 
maintaining  and  testing  AFSATCOM  operational  software.  Specification 
and  procurement  of  this  SMF  are  the  responsibility  of  ESD.  The 
procurement  action  will  begin  in  January  1977- 

Tne  SMF  development  contract  is  expected  to  be  completed  by  January 
1979,  at  which  time  the  SMF  will  be  physically  moved  to  Tinker  AFB  and 
run  by  the  Air  Force  Communications  Service  (AFCS).  The  CCPC  is  to  be 
responsible  for  all  application  software  maintenance  during  the 
operational  phase. 

Among  the  requirements  stated  in  the  Prime  Item  Development 
Specification  for  AFSATCOM  Software  Maintenance  Facility  [21]  are: 

• "The  SMF  shall  provide  assembly,  load,  edit,  debug  and  IPL  build 
capabilities . " 

• "The  SMF  shall  provide  the  capability  to  assemble  source  code 
software  modules  input  via  punched  cards,  punched  paper  tape, 
nine-track  magnetic  tape  or  magnetic  disk  file.  The  resultant 
object  code  modules  shall  be  stored  in  magnetic  disk  files  or  on 
punched  paper  tape.  The  capability  to  printout  assembly 
listings  as  well  as  a cross-reference  list  of  all  program  labels 
shall  be  provided.'-' 

• "The  SMF  shall  provide  the  capability  to  perform  an  edit 
function  controlled  via  inputs  from  a CRT  terminal.  This 
function  shall  allow  the  manipulation  of  data  (source  or  object, 
etc.)  in  magnetic  disk  files." 

• "The  SMF  snail  provide  access  to  magnetic  disk  files  for  the 
purposes  of  storage  and  retrieval . Data  to  be  stored  in  disk 
files  shall  be  input  via  punched  cards,  nine-track  magnetic 
tape,  CRT  or  punched  paper  tape.  Data  retrieved  from  disk  files 
shall  be  output  to  nine-track  magnetic  tape,  punched  paper  tape, 
printer,  CRT,  or  transferred  to  another  disk  file." 

• "The  SMF  shall  provide  the  capability  of  on-line  access  to  core 
memory  permitting  the  modification  or  read-out  of  the  contents 
of  discrete  program  addresses  (both  data  and  instructions)  via 
the  external  control  panel." 

• "The  SMF  shall  provide  the  capability  to  perform  the  IPL  build 
function  to  generate  the  necessary  four-track  magnetic  tape  (for 
the  magnetic  tape  memory  unit)  containing  the  AFSATCOM  operating 
program  in  the  required  initial  program  load  format.  This 
function  shall  be  utilized  to  generate  all  new  magnetic  tapes 
required  for  the  AFSATCOM  system." 
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• "The  SMF  shall  provide  the  capability  of  executing  program 
modules  under  the  control  of  the  standard  ROLM  DEBUG  utility 
program.  Interactive  control  and  on-line  program  examination 
and  modification  shall  be  accomplished  via  a CRT  terminal." 

• "For  its  software  testing  function,  the  SMF  shall  be  capable  of 
simulating  the  operation  of  any  AFSATCOM  MPU-terminal , airborne 
or  ground . . . . " 

• "The  SMF  shall  be  capable  of  loading  any  or  all  data  inputs  to 
the  AFSATCOM  message  processor  and  of  monitoring  all  data 
outputs  of  the  message  processor." 

• "Furthermore,  the  SMF  shall  be  capable  of  simulating  device 
failures  for  any  of  the  modems,  cryptos,  and  I/O's  which 
interface  with  the  AFSATCOM  message  processor." 

• "The  SMF  shall  be  comprised  of  the  following  functional 

subsystems:  Message  Processor  Subsystem,  Black  Interface 

Simulator  Subsystem,  Red  Interface  Simulator  Subsystem,  Program 
Maintenance  Peripherals  Subsystem,  and  the  Control  Software 
Subsystem. " 

• "The  Program  Maintenance  Peripheral  Subsystem  shall  consist  of 
the  peripheral  devices  for  the  message  processor  which  are 
required  to  perform  the  program  maintenance  function." 

• "The  Control  Software  Subsystem  shall  consist  of  disk  operating 
system  (DOS)  software  to  be  used  in  either  the  RED  or  BLACK 
Processor  in  conjunction  with  the  Program  Maintenance 
Peripherals  and...." 

• "The  DOS  software  shall  provide  comprehensive  file  system 
capabilities  (load,  assemble,  debug,  and  edit)  as  well  as 
diagnostics  on  either  processor  and  the  maintenance 
peripheral s . " 

COBRA  DANE  Facilities 


The  primary  development  contract  for  COBRA  DANE  was  awarded  to 
Raytheon  Company,  Way land,  Mass,  in  June  of  1973-  Raytheon  selected  and 
acquired  the  data  processing  equipment  including  a CDC  CYBER  74-18  as 
the  main  processor.  Raytheon  subcontracted  the  development  of  mission 
and  off-line  software  for  the  CYBER  74-18  to  SDC.  SDC  began  software 
development  at  Raytheon's  Way land,  Mass,  plant  where  Raytheon  was 
assembling  the  operational  system  hardware.  The  system  has  since  been 
deployed  at  Sheyma  AFB,  Alaska  where  SDC  continued  to  develop  the 
mission  programs. 


A CDC  CYBER  74-14  has  been  acquired  to  handle  the  post  mission 
processing  and  data  reduction  programs  since  these  programs  cannot  be 
run  concurrently  with  the  primary  mission  programs.  CDOS,  a slightly 
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modified  version  of  SCOPE  3 - ^ , is  used  as  the  CYBER  74-18  operating 
system . 

The  contract  with  Raytheon  carries  a built-in  one-year  maintenance 
period  beyond  the  Initial  Operational  Capability  (IOC).  This 
maintenance  will  be  accomplished  using  both  the  operational  system  on- 
site and  a CDC  6600  (functionally  equivalent  to  a CYBER  74-18)  located 
at  the  Air  Force  Geophysics  Laboratory  at  Hanscom  AFB.  Beyond  the  one- 
year  contract,  continued  development  and  maintenance  will  be  the 
responsibility  of  ADCOM. 

COMBAT  GRANDE  Facilities 

In  February  of  1974,  the  prime  system  contract  was  awarded  to  C0MC0 
Electronics  Corporation  of  Fullerton,  California.  COMCO  has  been 
responsible  for  acquisition  of  all  computer  hardware  and  development  of 
almost  all  application  software  (i.e.,  part  of  the  applications  has  been 
subcontracted  to  Sylvania).  For  approximately  the  first  nine  months  of 
the  contract,  COMCO  used  a Hughes  H—  4118  computer  at  Hughes  Aircraft 
Company's  computer  center.  Ar.  IBM  System  370  connected  to  remote 
terminals  at  COMCO  provided  a capability  to  check  out  operational  Hughes 
H5118M  programs  through  use  of  an  interactive  simulator. 

By  the  tenth  month  COMCO  had  established  its  COMBAT  GRANDE 
Fullerton  Test  Facility  and  had  acquired  its  own  Hughes  H5118M.  During 
the  first  year  and  a half,  COMCO  assembled  at  the  Fullerton  Test 
Facility  the  full  complement  of  computer  resources  that  will  be  deployed 
in  Spain,  including  a second  H5118M  with  peripherals,  displays, 
controllers,  etc. 

The  Fullerton  Test  Facility  is  dedicated  to  the  development  of 
COMBAT  GRANDE  software.  COMCO  has  used  the  Fullerton  Test  Facility  for 
development  of  the  operational  computer  program,  other  application 
programs,  diagnostic  programs,  utility  programs,  simulation  program,  and 
data  reduction  programs.  The  programs  are  coded  in  JOVIAL  and  assembly 
language . 

The  Central  Computer  Utility  Program  which  operates  on  the  H5118M 
is  used  to  produce  and  maintain  parts  of  the  Operational  Computer 
Program  and  utilities  that  operate  on  the  H5118M.  It  includes  a JOVIAL 
compiler,  data  assemblers,  master  tape  generator,  magnetic  tape 
operations,  adaptation  calculator  and  miscellaneous  program  maintenance 
tools.  Some  of  these  programs  are  newly  developed. 

A set  of  support  programs  also  exist  for  producing  and  maintaining 
application  and  utilities  that  execute  in  the  controller  computers. 

They  include  assemblers,  tape  generators,  and  miscellaneous  program 
check-out  tools  (off-the-shelf  and  commercially  available)  and  execute 
on  the  PDP  11/05  and  TI-980A  computers. 

The  Sector  Operations  Center  data  processing  equipment  will  be 
moved  to  Torre jon,  Spain  where  system  testing  will  be  performed.  COMCO 
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will  continue  as  prime  contractor  until  the  end  of  system  testing. 
Because  of  the  complete  duality  of  equipment  at  the  Sector  Operations 
Center,  the  backup  equipment  will  comprise  an  SMF  for  continued  software 
j modification,  test  and  maintenance. 

i 

CONUS  OTH-B  PRS  Facilities 

In  March  of  1975,  the  General  Electric  Company  of  Syracuse,  New 
York  was  chosen  as  the  prime  contractor.  The  computer  hardware  selected 
for  the  PRS  by  General  Electric  includes: 

• A UNIVAC  1110  computer  to  be  located  at  the  Operations  Site  as 

, the  central  data  processor. 

• Two  UNIVAC  1616  computers,  one  to  be  located  at  the  Transmit 
Site  and  one  to  be  located  at  the  Receive  Site  as  radar  control 
and  monitor  equipment.  (The  Receive  and  Operations  Sites  will 
be  collocated.) 

• A programmable  Modular  Processing  System  (MPS)  built  by  General 
Electric,  to  be  located  at  the  Receive  Site  as  a signal 
processor . 

General  Electric  has  subcontracted  the  majority  of  the  software 
development  for  computer  programs  which  will  be  executed  on  the  UNIVAC 
1110,  to  TRW  Systems,  Inc.,  of  Redondo  Beach,  California.  General 
Electric  will  develop  the  remainder  of  the  software  required  for  the 
PRS. 

The  PRS  will  have  two  SDF's.  The  Central  Data  Processor  SDF  at 
TRW,  Redondo  Beach  and  the  OTH  Integrated  Test  Facility  at  General 
Electric,  Syracuse.  A combined  General  Electric  and  TRW  team  will  use 
the  Central  Data  Processor  SDF  for  developing  most  of  the  functional  and 
application  computer  programs.  TRW  will  be  responsible  for  overall 
process  integration  and  in-plant  testing  for  the  computer  programs 
developed  at  this  SDF. 

. 

The  OTH  Integrated  Test  Facility  will  be  used  by  General  Electric 
as  the  SDF  for  the  computer  programs  which  will  be  executed  on  the 
UNIVAC  1616 's,  as  well  as  the  computer  programs  which  will  be  executed 
on  the  Signal  Processor.  The  computer  hardware  configuration  of  this 
SDF  is  identical  to  the  configuration  that  will  be  used  at  the  Receive 
Site.  Using  this  SDF,  General  Electric  will  develop  the  radar  control 
and  monitor  programs,  the  data  recording  programs  and  the  maintenance 
and  diagnostic  programs  for  the  Transmit  and  Receive  Site  computers. 
General  Electric  will  also  use  this  SDF  and  diagnostic  programs  which 
will  be  executed  on  the  Signal  Processor.  These  computer  programs  will 
be  developed  using  assemblers,  simulators,  and  debug  utilities  which  are 
executed  on  the  UNIVAC  1 6 1 6 . 

The  components  from  these  SDF's  will  not  be  assembled  and  tested  as 
a complete  system  until  they  are  delivered  to  the  PRS  sites  in  Maine. 
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The  Receive  Site  and  the  Operations  Site  will  be  collocated,  and  the 
facility  will  function  as  an  operational  prototype  as  well  as  a SDF  and 
a SMF  for  the  life  of  the  PRS. 

JSS  Facilities 


The  JSS  RFP  package  was  released  in  October  1976.  Two  contractors 
will  be  initially  selected  and  will  compete  in  a "fly-off"  - a parallel 
validation  phase  during  which  each  contractor  will  concentrate  on 
designated  high  risk  areas  (e.g.,  operating  system,  tracking,  displays). 
After  15  months,  a single  contractor  will  be  chosen  for  the  full-scale 
development  and  production  phases. 

It  is  expected  that  software  development  will  be  accomplished  in- 
plant  by  the  contractor.  The  first  Regional  Operations  Control  Center 
(ROCC)  to  be  installed  is  the  CONUS  Southeast  (SE)  quadrant.  At  the 
same  time,  the  contractor  is  to  install  what  is  called  a ROCC  System 
Support  Facility  (RSSF)  to  be  collocated  with  the  SE  quadrant  ROCC.  A 
System  Support  Element  specification  defines  the  RSSF  requirements.  The 
RSSF  tasks  will  include: 

• System  software  support 

- Modification 

- Redesign 

- Test 

- Documentation 

- Program  support  library 

- Generation  of  exercise  files 

• Displaced  SE  ROCC  operations 

• Training 

The  system  is  to  be  acquired,  where  possible,  using  "off-the-shelf" 
components.  No  hardware  research  and  development  is  anticipated  with 
the  possible  exception  of  displays.  The  RSSF  equipment  configuration  is 
undetermined,  but  it  will  closely  approximate  a ROCC. 

Before  system  Final  Operational  Capability  (FOC),  the  RSSF  will  be 
used  to  train  operational  personnel  and  to  familiarize  the  using 
organizations  with  the  software.  After  FOC,  the  RSSF  will  support 
design  and  maintenance  of  all  ROCC  software  as  well  as  generation  of 
system  exercise  tapes.  Testing  of  new  versions  of  ROCC  software  will  be 
performed  using  the  SE  ROCC  resources  with  the  RSSF  temporarily  assuming 
the  operational  mission. 

JTIDS/ASIT  Facilities 

The  JTIDS/ASIT  system  is  one  of  the  JTIDS  system  procurements  and 
was  in  source  selection  as  of  August  1976. 

According  to  the  SOW  [22], 
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"support  software  for  development  of  the  Operational  Computer 
Program  (OCP)  shall  operate  on  a contractor  defined  computer 
system,  identified  in  the  CPDP,  subject  to  procuring 
activity  approval." 

The  Operational  Computer  Program,  auxiliary  programs  (i.e.,  Data 
Reduction  Program  and  Exercise  Preparation  Program),  and  Information 
Distribution  Network  software  (if  proposed),  will  be  developed  on 
contractor  provided  facilities.  Certain  parts  of  the  development  may 
require  a secure  facility  (classified).  The  auxiliary  programs  need  not 
be  developed  on  the  same  facility  as  the  Operational  Computer  Program. 

The  support  hardware  need  not  be  deliverable. 

According  to  the  SOW  [22], 

"deliverable  support  software  shall  include  all  programs 
required  to  maintain,  update  and  modify  all  operational  and 
support  programs  delivered  under  this  contract,  with  the 
support  computer(s)  (i.e.,  standard  operating  system,  file 
system,  ANSI  compatible  compilers,  loaders)." 

It  is  anticipated  that  the  contractor  will  perform  program  maintenance. 
There  are  presently  no  plans  for  Government  maintenance  of  this 
software . 

According  to  the  SOW  [22 J: 

• "The  support  software  shall  support  all  phases  of  the 
contract  including  software  development,  in-plant  testing  and 
field  testing  through  IOT&E." 

• "No  development  of  support  software  or  development  aids 
shall  be  done,  except  for  development  described  in  CPDP  as 
reviewed  by  the  procuring  activity." 

In  regards  to  Operational  Computer  Program  support  software: 

• "All  support  software  shall  be  capable  of  being  executed  on 
any  installation  of  the  support  computer  using  a standard 
operating  system." 

• "The  support  software  shall  include,  but  not  be  limited  to: 
assembler,  compiler,  binder,  loader  and  microprocessor 
software . " 

The  assembler  and  compiler  are  to  be  "off-the-shelf".  Detailed 
requirements  for  the  assembler,  binder  and  compiler  are  also  specified 
in  the  SOW. 

The  SOW  also  requires  that  a program  support  library  be  implemented 
and  maintained  throughout  the  software  development  phases  of  the 
contract.  The  library  functions  required  include  source  data 
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maintenance,  output  processing,  programming  language  support  and  library 
system  maintenance.  If  microprocessors  are  proposed,  the  contractor  is 
to  provide  the  "support  software  needed  to  develop,  produce,  operate, 
test,  modify,  and  maintain  the  microprocessor  software."  The  ASIT  RFP 
also  requires  full  data  rights  to  all  firmware  and  firmware  development 
tools. 

MACIMS  Facilities 


MAC  developed  the  IOC  subsystems  in-house  at  Headquarters  MAC  using 
basically  standard  WWMCCS  hardware  and  software.  Application  software 
was  developed  on  the  same  facilities  presently  used  for  operation. 
Computer  Systems  1 and  2 are  used  for  continued  development  and 
maintenance  of  application  software  in  addition  to  operations.  System  1 
supports  other  processing  besides  MACIMS  (e.g.,  Major  Command  programs). 
Systems  4 and  5 are  dedicated  to  operation  of  the  cargo  and  passenger 
subsystems,  but  are  occasionally  used  for  testing  program  changes. 

System  1 is  a WWMCCS  Force  Control  system  with  dual  processor 
H6080's.  System  2 is  a WWMCCS  Force  Control  system  with  a single 
processor  H6080,  and  Systems  4 and  5 are  WWMCCS  General  Staff  Support 
Medium  H6050  systems.  Each  system  includes  WWMCCS  DATANET  355  front-end 
communication  processors.  The  support  software  used  on  these  systems  is 
the  standard  WWMCCS  GCOS  and  its  associated  compilers,  assembler,  and 
utilities.  A number  of  performance  monitoring  tools  were  obtained 
through  other  Air  Force  agencies. 

A Honeywell  System  700  minicomputer  was  installed  at  Headquarters 
MAC  and  used  to  modify  the  minicomputer  software  and  test  the  remote 
interfaces.  This  system  was  an  expansion  of  the  operational  cargo  port 
configuration  and  included  additional  peripherals  and  core  to  support 
application  program  development.  A batch  operating  system  was  used  for 
software  development.  Special  test  packages  were  also  developed 
internally  by  MAC  to  check  out  minicomputer  systems. 

PAVE  PAWS  Facilities 

The  contract  for  one  system  (Otis  AFB)  was  awarded  in  April  1976  to 
Raytheon  Company,  Wayland , Mass.  Raytheon  selected  the  computer 
hardware  including  the  CDC  CYBER  174-12  as  the  main  processor  and  the 
MODCOMP  IV/25  as  the  radar  controller.  Raytheon  subcontracted 
development  of  the  CYBER  174-12  operating  system  (an  adaptation  of  CDC's 
Network  Operating  System)  to  CDC.  CDC  will  also  supply  various  off-the- 
shelf  support  software.  IBM  was  subcontracted  to  develop  all  other 
software  for  the  CYBER  174-12.  Raytheon  will  develop  software  for  the 
MODCOMP  IV/25*.  and  for  their  own  signal  processor. 

The  following  CPCI 's  will  be  developed: 

CDC  - (CPCI.1)  PPOS  (PAVE  PAWS  Operating  System) 

IBM  - (CPCI. 2)  Tactical  Applications  Software 

- (CPCI. 3)  Simulation  Software 
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Raytheon 


(CPCI.4)  Structured  Programming  Development  Tools 
(CPCI.5)  Data  Reduction  Tools 
(CPCI.6)  Radar  Controller  Software 
(CPCI.7)  Signal  Processor  Software 


The  SDF  is  at  Raytheon  and  includes  two  CYBER  174  computers,  one 
radar  controller,  display  consoles  and  peripheral  devices.  The 
Structured  Programming  Development  Tools  (CPCI.4)  include  a JOVIAL 
preprocessor,  COMPASS  preprocessor,  program  support  library,  and  report 
generator  programs. 


The  SDF  at  Raytheon  will  be  delivered  to  Otis  AFB  (Site  1). 
Raytheon  may  keep  Beale  AFB  (Site  2)  hardware  in-plant  for  some  time 
after  Site  1 deployment,  but  eventually  the  SDF  functions  are  to  be 
assumed  by  the  Site  1 system.  The  SDF  hardware  is  being  acquired 
entirely  by  Raytheon.  The  SDF  will  be  managed  by  Raytheon  while  it  is 
at  their  facility.  After  IOC  and  turnover,  on-site  development  and 
maintenance  will  be  the  responsibility  of  ADCOM. 


The  site  SDF  will  be  used  for: 

• System  operations 

• Program  development 

• Program  modification 

• Program  debugging  and  test 

• System  maintenance  and  documentation 

• Hardware  testing 

• Simulation  exercises 


TRI-TAC  Facilities 

In  December  of  1974,  the  performance  specification  for  the 
Communications  System  Control  Element  (CSCE)  and  Communications  Nodal 
Control  Element  (CNCE)  of  the  TCCF  were  completed.  In  May  1975,  a 
contract  was  awarded  to  Martin-Marietta  for  development  and  delivery  of 
two  CSCE's  and  six  CNCE's.  Martin-Marietta  subcontracted  all  data 
processing  hardware  and  software  to  UNIVAC. 

The  Defense  Systems  Division  of  UNIVAC  in  St.  Paul,  Minnesota  is 
building  or  purchasing  the  data  processing  hardware.  Hardware 
development  is  required  for  the  UNIVAC  U-1600  and  Data  Bus  Controller. 
UNIVAC  will  also  supply  the  support  software,  including  off-the-shelf  or 
adapted  operating  systems,  data  management  systems,  compilers, 
assemblers,  etc. 

The  SDF  for  application  software  was  established  at  the  UNIVAC 
Technical  Services  Division  in  Houston.  The  SDF  will  be  moved  to 
Martin-Marietta's  Orlando,  Florida  facility,  but  will  still  be  operated 
by  UNIVAC.  This  will  be  a dedicated  facility  and  the  Houston  facility 
will  be  phased  out. 
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A CSCE  and  one  or  more  CNCE's  are  to  be  moved  to  the  Fort  Huachuca 
Test  Bed,  where  a joint  Army,  Navy,  and  Air  Force  team  will  begin  an 
estimated  two-year  period  of  testing.  Martin-Marietta  and  UNIVAC  are 
expected  to  be  heavily  involved  throughout  this  period  of  testing.  A 
second  CSCE  and  at  least  two  CNCE's  will  most  likely  remain  in  the 
Orlando  facility,  so  it  is  probable  that  the  primary  SDF  will  continue 
to  be  in  Orlando  even  after  testing  is  under  way.  However,  some 
software  modification  and  testing  may  be  conducted  at  the  test  site. 
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APPENDIX  C 

TYPES  OF  SUPPORT  SOFTWARE 


The  types  of  support  software  discussed  below  are  representative  of 
those  types  encountered  in  the  surveyed  systems.  The  list  is  not 
intended  to  be  all  encompassing,  but  it  includes  the  most  important 
types  of  support. 

Operating  Systems 

According  to  one  definition,  an 

"operating  system  is  a collection  of  programs  (algorithms) 
designed  to  manage  system  resources;  namely,  memory,  processors, 
devices,  and  information  (programs  and  data)"  [23]. 

Application  or  support  software  (e.g.,  compilers)  generally  request  use 
of  system  resources  through  an  operating  system.  In  some  cases  support 
software  may  operate  in  a stand-alone  mode  with  no  operating  system. 
Examples  of  operating  systems  are  IBM's  System  370  Virtual  Storage  1, 
IBM's  System  360  Operating  System,  UNIVAC's  1108  EXEC  8,  and  Data 
General's  Real  Time  Disk  Operating  System. 

Compilers 

According  to  one  source,  a compiler  is  a program 

"which  translates  a source  program  written  in  a particular 
programming  language  to  an  object  program  which  is  capable  of 
being  run  on  a particular  computer"  [24]. 

Compilers  exist  for  such  computer  languages  as  FORTRAN,  COBOL  and 
JOVIAL.  A cross-compiler  is  a compiler  that  operates  on  a host  machine 
with  an  instruction  set  different  from  the  one  on  which  the  compiled 
program  is  executed.  For  example,  a FORTRAN  program  may  be  compiled  on 
an  IBM  System  370  and  executed  on  a Data  General  NOVA. 

Interpreters 

An  interpreter  differs  from  a compiler  in  that  it  is 

"a  program  which  executes  a source  program,  usually  on  a step- 
by-step,  line-by-line,  or  unit-by-unit  basis"  [24]. 

Interpreters  exist  for  such  languages  as  BASIC,  APL,  and  SN0B0L. 

Assemblers 

An  assembler  is  a program  which  translates  assembly-level  code 
(symbolic  code)  to  machine  code  that  is  executable  by  the  computer.  A 
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cross-assembler  is  an  assembler  that  executes  on  a host  machine  with  an 
instruction  set  different  from  that  on  which  the  assembled  program  is 
run.  Some  assemblers  have  macro  capabilities.  Macros  provide  a 
capability  to  define  a sequence  of  instructions  with  alternative  types 
of  expansion  using  macro  parameters.  Macro  calls  are  coded  in-line  with 
assembly  statements.  Each  macro  call  is  expanded  into  assembly 
statements  according  to  the  parameters  supplied. 

Linkage  Editors  and  Loaders 

A linkage  editor  is  a program  that  binds  the  object  modules 
generated  by  an  assembler  or  compiler  into  a unit  ready  for  loading.  It 
resolves  external  program  references.  A loader  loads  the  resulting 
program  into  memory.  In  some  cases,  the  linking  and  loading  functions 
are  performed  by  one  program.  A link  editor  or  loader  may  operate  in  a 
stand-alone  mode  or  under  control  of  an  operating  system. 

Utilities 


Utilities  are  support  programs  used  to  create,  edit,  sort,  merge 
and  maintain  system  or  user  program  libraries  and  files;  to  configure 
the  operating  system;  and  to  debug  or  test  application  programs. 
Utilities  may  operate  in  a batch  or  interactive  mode.  Some  typical 
examples  of  these  support  programs  are: 

• Library  Maintenance  Routines  - used  to  create  program  and 
data  libraries  (directories),  to  add  or  delete  directory 
items,  to  reorganize  libraries  (e.g.,  purge  and  reorder 
items)  and  to  dump/restore  libraries  from  disk  and  tape. 

• File  Maintenance  Routines  - used  to  copy,  sort,  and  merge 
files  on  several  types  of  media  (e.g.,  tape,  disk,  card). 

• Text  Editors  - used  to  edit  program  source  code  or  data. 

• Software  Diagnostic  and  Debug  Aids  - include  compile  and 
execution  time  debug  aids  that  help  identify  and  isolate 
program  errors.  These  capabilities  may  include  commands 
such  as  DUMP,  TRACE,  MODIFY,  and  BREAKPOINT.  The  aids  may 
provide  static  (batch)  or  dynamic  (real-time)  debug 
capabilities . 

Interpretive  Simulators 


Interpretive  simulators  are  programs  that  interpretively  execute 
each  instruction  of  a user  program  in  a simulated  environment.  The 
simulator  may  optionally  provide  execution  statistics.  In  some  cases, 
debugging  aids  are  incorporated  in  the  simulator  (e.g.,  breakpoints, 
dumps) . 
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Design  Aids 


Examples  of  automated  design  aids  are  design  languages  and  their 
associated  processors.  An  operational  program  can  be  described  in  a 
high  level  design  language  and  the  description  "executed"  to  verify  the 
design  logic.  In  some  design  languages,  as  each  module  of  the  program 
is  coded,  the  code  can  replace  the  design  language  description  and  be 
executed  with  the  other  modules.  A system  can  be  thus  propagated  from 
"design  code"  to  operational  code  by  this  process.  Decision  tables  are 
another  example  of  an  automated  design  aid.  Once  validated  these  tables 
may  be  manually  coded  or  automatically  translated  into  program  code. 

Language  Translators 

Language  translators  are  programs  that  translate  statements  in  one 
language  (e.g.,  FORTRAN)  to  statements  of  another  language  (e.g.,  PL/I). 

Language  Preprocessors 

A language  preprocessor  is  a program  that  preprocesses  source  code 
prior  to  its  input  to  another  processor  (e.g.,  compiler).  For  example, 
a program  described  in  structured  FORTRAN  may  be  translated  to  standard 
American  National  Standards  Institute  (ANSI)  FORTRAN  prior  to  input  to 
an  ANSI  FORTRAN  Compiler. 

Automated  Test  Tools 

Automated  test  tools  are  programs  which  generate  test  data  and 
evaluate  program  test  cases.  An  example  of  a test  case  generator  is  a 
program  that  automatically  prepares  a sequence  of  input  data  based  on 
input  parameters;  hence,  various  combinations  or  time-ordered  sequences 
of  input  data  can  be  easily  prepared . 

Documentation  Aids 

Documentation  aids  are  programs  that  automatically  generate  program 
documentation  from  source  code  or  library  descriptions.  An  automatic 
flowcharter  is  one  example.  Another  example  is  a program  that  produces 
a "picture"  of  the  program  structure  (e.g.,  hierarchical  top-down 
description)  based  on  the  program  library  directory. 

Report  Generators 

Report  generators  are  programs  used  to  produce  reports  from 
formatted  computer  files.  They  are  not  generally  considered  compilers 
in  the  sense  that  the  language  processed  is  not  a programming  language. 
IBM's  System  360  Report  Program  Generator  (RPG)  and  SDC 's  DS/2  are 
examples  of  report  generators. 
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Modelling  Tools 

Included  among  these  tools  are  languages  such  as  GPSS  and  SIMSCRIPT 
which  facilitate  the  writing  of  system  simulation  programs. 

External  Emulators 


These  tools  include  a combination  of  hardware  and  software  used  to 
emulate  external  input  data  to  a system.  For  example,  an  emulator  may 
generate  peripheral,  terminal,  or  intercomputer  input. 

Hardwat  Monitors 


Hardware  monitors  are  collections  of  equipment  (probes,  cables, 
logic  boards,  counters,  and  data  recorders)  directly  attached  to  a 
computer's  circuitry,  which  sample  pulses  representing  data  flowing 
through  the  computer . A computer  keeps  track  of  the  number  of 
occurrences  or  duration  of  particular  signals  and  records  the 
accumulated  data  on  a recording  device  (e.g.,  magnetic  tape).  These 
data  are  reduced  (e.g.,  using  data  reduction  and  analysis  programs)  to 
obtain  information,  for  example,  about  CPU  and  channel  utilization. 

Based  on  this  information,  inefficiencies  may  be  located  and  remedied. 

Sof tware  Monitors 

A software  monitor  is  a program  that  resides  in  computer  memory  and 
gathers  data  about  the  system's  performance.  It  may  operate  as  a high 
priority  application  program  or  as  part  of  the  operating  system.  The 
monitor  gathers  data  about  the  changing  status  of  the  system  by  reading 
operating  system  internal  tables,  control  blocks,  registers,  and  memory 
maps.  As  in  the  case  of  hardware  monitors,  these  data  can  be  recorded 
and  analyzed. 

Hardware  Diagnostics 

Hardware  diagnostics  are  on-line  or  off-line  computer  programs,  or 
firmware,  used  to  detect  and  isolate  processor,  memory,  peripheral, 
communication , and  other  types  of  hardware  malfunctions. 

Microprogramming  Development  Tools 

These  tools  are  a combination  of  hardware  and  software  resources 
used  to  generate  and  test  microprograms.  Examples  of  such  support 
include  the  INTEL  8080  PL/M,  assembler,  and  loader.  In  many  facilities, 
a special  microprogramming  laboratory  is  set  up  to  develop 
microprograms.  In  most  cases,  the  support  is  host-resident. 

Data  Reduction  and  Analysis  Tools 

These  tools  are  statistical  packages  used  to  analyze  system  data. 

An  example  of  such  a tool  is  a program  that  reduces  input  data 
reviously  recorded  by  a hardware  or  a software  monitor  and  derives 
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utilization  statistics,  allocation  statistics,  and  performance 
indicators . 


Requirements  Analysis  Aids 


Examples  of  these  aids  are  problem  statement  languages  and  their 
associated  processors.  System  requirements,  including  functional 
processes,  luterfaces,  input,  and  output,  can  be  stated  as  problem 
language  statements.  These  statements  can  be  stored  in  a data  base, 
updated  as  required,  analyzed  for  consistency,  and  accessed  for  report 
generation . 
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LIST  OF  ABBREVIATIONS 


Abbreviation 


Definition 


AABNCP 

ADCOM 

ADP 

AFCS 

AFGL 

AFLC 

AFSATCOM 

ALC 

ANSI 

ASIT 

ASPR 

ATC 

AWACS 

CCPC 

CDC 

CDR 

CDRL 

Cl 

CNCE 

CONUS 

CP 

CPCI 

CPDP 

CPPF 

CPS 

CPU 

CR 

CRISP 

CRT 

CRWG 

CSC 

CSCE 

CSS 

DoD 

DODD 

DODI 

DOS 

DT&E 

ECCM 

ESD 

FOC 

FQT 

GCOS 

GE 

GFE 

GFP 

GMAP 

IOC 


Advanced  Airborne  Command  Post 

Aerospace  Defense  Command 

Automatic  Data  Processing 

Air  Force  Communications  Service 

Air  Force  Geophysics  Laboratory 

Air  Force  Logistics  Command 

Air  Force  Satellite  Communications 

Air  Logistics  Center 

American  National  Standards  Institute 

Adaptable  Surface  Interface  Terminal 

Armed  Services  Procurement  Regulations 

Air  Training  Command 

Airborne  Warning  and  Control  System 

Communications  Computer  Programming  Center 

Control  Data  Corporation 

Critical  Design  Review 

Contract  Data  Requirements  List 

Configuration  Item 

Communications  Nodal  Control  Element 
Continental  United  States 
Card  Punch 

Computer  Program  Configuration  Item 
Computer  Program  Development  Plan 
Computer  Programming  Production  Facility 
Core  Processing  System 
Central  Processing  Unit 
Card  Reader 

Computer  Resources  Integrated  Support  Plan 
Cathode  Ray  Tube 

Computer  Resources  Working  Group 
Computer  Sciences  Corporation 
Communications  System  Control  Element 
Communications  System  Segment 
Department  of  Defense 
Department  of  Defense  Directive 
Department  of  Defense  Instruction 
Disk  Operating  System 
Development,  Test  and  Evaluation 
Electronic  Counter  Counter  Measures 
Electronic  Systems  Division 
Final  Operational  Capability 
Formal  Qualification  Test 
General  Comprehensive  Operating  System 
General  Electric 
Government  Furnished  Equipment 
Government  Furnished  Property 
General  Macro  Assembly  Program 
Initial  Operational  Capability 
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LIST  OF  ABBREVIATIONS  (Concluded) 


Abbreviation 


Definition 


IOT&E 

IPL 

JSS 

JTIDS 

MAC 

MACIMS 

MDS 

MPS 

NCMC 

NCS 

NORAD 

0/S  CMP 

OS 

OT4E 

OTH-B 

PAWS 

PDR 

PMD 

PMP 

PQT 

PROM 

PRS 

RFP 

ROCC 

RPG 

RSSF 

S/370 

SAC 

SATIN  IV 

SCC 

SDC 

SDF 

SE 

SMF 

SOW 

S3F 

STATF 

TAC 

TACC 

TCCF 

TDM  A 

WWMCCS 


Initial  OT&E 
Initial  Program  Load 
Joint  Surveillance  System 

Joint  Tactical  Information  Distribution  System 
Military  Airlift  Command 

Military  Airlift  Command  Integrated  Management  System 

Modular  Display  System 

Modular  Processing  System 

Z 3 AD  Cheyenne  Mountain  Complex 

NORAD  Computer  System 

North  American  Air  Defense  Command 

Operational/Support  Configuration  Management  Procedures 

Operating  System 

Operational  Test  and  Evaluation 

Over-the-Horizon  Backscatter 

Phased  Array  Warning  System 

Preliminary  Design  Review 

Program  Management  Directive 

Program  Management  Plan 

Preliminary  Qualification  Test 

Programmable  Read-Only  Memory 

Prototype  Radar  System 

Request  for  Proposal 

Regional  Operations  Control  Center 

Report  Program  Generator 

ROCC  System  Support  Facility 

IBM  System  370 

Strategic  Air  Command 

SAC  Automated  Total  Information  Network 
Space  Computational  Center 
System  Development  Corporation 
Software  Development  Facility 
Southeast 

Software  Maintenance  Facility 

Statement  of  Work 

Software  Support  Facility 

Staging  and  Test  Facility 

Tactical  Air  Command 

Tactical  Air  Control  Center 

Tactical  Communications  Control  Facilities 

Time  Division  Multiple  Access 

World  Wide  Military  Command  and  Control  System 
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